Integration tests and private interfaces


#1

I have started implementing integration tests for a toy project. Unfortunately, I find myself forced to expose internals in the public interface just to be able to write some useful tests.

Is there a way to avoid this via conditional compilation?


#2

I’m confused: If it is a private interface, you shouldn’t write integration tests for it. What kind of functionality do you need to expose there?

Unit tests in the crate are the appropriate way for doing this.

If you absolutely must, you can have a module like this in your lib.rs:

#[cfg(test)]
pub mod testsupport {
    // public reexports of otherwise private things
}

#3

Keep in mind that such things could be a hint that your design might not be optimal. I had a similar issues with an API I was working on that consumed some input values by move. After rethinking and changing the design it becomes easier to test and more flexible to use. But it really depends on the actual code, so maybe you can show your code or the relevant parts of it.


#4

@skade, this won’t work. When you import your crate in an integration test, the imported crate is not built in test mode.

@kunerd, I’m in the middle of a rewrite, but it boils down to this: I have a backend crate and a frontend crate. The backend has access to a database. Tests need the connection in order to build fixtures. However, the frontend should never touch the database directly. So, I’d like to expose a getter on the connection for the tests, but this should not be part of the public interface.


#5

If your integration tests are part of the same crate than you can use pub(crate).


#6

@HaronK, sounds like a good idea, thanks.