What it does

Check for mod test {}s and instead encourage those being separate files.

Checking for mod test {} was to align with tests_outside_test_module. I could imagine there being other cases to key off of.

Advantage

Rebuild performance. If someone changes a "unit test", then only the test lib rebuilds and not the lib.

• matklad blogged about this pattern at https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html#Assorted-Tricks
• rustc has a tidy check for this, see https://github.com/rust-lang/rust/blob/HEAD/src/tools/tidy/src/unit_tests.rs
• The Cargo team was suggesting it to someone at https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/upstream.20test-only.20code.20change.20triggers.20downstream.20rebuilds/near/477693957

Drawbacks

For foo.rs files in projects that use foo/mod.rs, adding a separate test mod would require creating a directory when it wasn't needed otherwise. Except for when visibility is a concern, a parallel test_foo.rs file could be used, e.g. snapbox does this

Overall, this would increase the friction for writing tests.

Example

#[cfg(test)]
mod test {
}

Could be written as:

#[cfg(test)]
mod test;