How to create mock response objects for testing

[Edward Rudd]

Previous to #251 I was able to call parse to create mock response objects to use in my application testing. With the latest update I am no longer able to do that.

So the question is how can we provide that functionality to allow a user of the crate to mock and write tests for their code that calls the imap crate without having an imap server setup.

In my case I am using the mock_double crate to do things like this.

            imap.expect_get_acl()
                .withf(|email: &String| email == "user/[e-mail]")
                .returning(|_email| {
                    let (mut tx, _rx) = mpsc::channel();
                    let response = b"* ACL INBOX [e-mail] lrwpx\r\n".to_vec();

                    AclResponse::parse(response, &mut tx)
                });

I know we had discussed on the ACL/quota PRs about how to create a better way of exposing this. But now that this has been removed we should discuss this again to figure out a clean solution to allow building response objects for the purpose of mocking and testing.

[Edward Rudd]

What about exposing (with a feature flag?) the response builders into a separate namespace.

e.g. imap::testing::parse_acl_response(...) -> AclResponse

This could be hidden behind a feature flag of test_helpers

Thus a consumer of the library could do this.

[dependencies]
imap = "3.0.0.alpha"

[dev-dependencies]
imap = { version = "3.0.0-alpha", features = ["test-helpers"] }

This way those would only be available in testing mode and not your everyday usage mode.

I'm creating a PR that shows this way of doing things.

[Jon Gjengset]

That's a good point — I think it makes a lot of sense to expose builders for generating objects for test purposes. We just need to be careful that we don't open up potential backwards-compatibility hazards where we won't be able to add fields to structs or change their internal composition in the future!