“Internal” unit tests have, in some cases, many usability advantages over “external” unit tests, the main one for me personally being that they can be generated from macros and procedural macros, to directly insert test for the functionality being added that exercise the actual types. For example,
derive(Foo) can insert
cargo test pattern one can control which unit tests are run, but not which tests are compiled. This can introduce compilation time problems if a crate has many unit tests.
The current ways of controlling which tests are compiled have big downsides:
split tests into different files:
tests/subset_a.rs- this has the downside that the implementation and the tests become separated and that crates might need to export macros just for testing purposes.
add feature flags, and
#[cfg(all(test, feature = "sub_tests_A"))]instead of just
#[cfg(test)]: this is problematic because one cannot add “dev” features, so these testing-only features become part of the API of a crate. They also recompile the whole crate every time, even though only the tests must be recompiled when they change.
use a cfg flag
RUSTFLAGS="--cfg test_subset_A" cargo test. Same problems as above, but worse, because now all crates in the dependency graph of the dev target must be recompiled.
I would like to be able to control, in a finer-grained way, which internal tests are compiled and run. and run all tests of a particular submodule, or of a submodule or its submodules.