Closed urkle closed 1 year ago
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.
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!
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.
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.