AFAICT there is still no good way to write integration tests for binary crates. The options seem to be:
- Add a
src/lib.rsto the crate root, make
src/main.rsa thin wrapper around that, and have the integration tests import the crate as a library. The problem with this approach is that publishing the crate to crates.io will publish the library as well as the binary. That’s a problem if the library isn’t intended to have a stable API.
- Move the integration tests into the
src/directory, building them as unit tests. This is a problem if the code is built differently when in
#[cfg(test)]mode. For example, my crate uses mock objects in test mode. I want my unit tests to use the mocks, but my integration tests musn’t.
- Create a workspace. Move most of the crate’s functionality into subcrates built as libraries, and write integration tests for those. This is the approach taken by the ripgrep crate. But it has the same problems as option 1 with regards to publishing.
Is there any solution that would allow me to test my code both with and without mock objects, but not publish a library to crates.io? The only idea I have is ugly: create a
mocks feature flag and have one set of unit tests that only run with
mocks enabled, and another set that run with