New inline_test_mod lint to encouage independent test.rs files for rebuild performance

[epage]

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;

[WiSaGaN]

I am a little confused by the drawback. I assume the drawback is if you are having src/foo.rs instead of src/foo/mod.rs, you would need to change to the latter to have a separate src/foo/test.rs to conform the separate test file pattern. Also, how does test_foo.rs work exactly?

[epage]

I am a little confused by the drawback. I assume the drawback is if you are having src/foo.rs instead of src/foo/mod.rs, you would need to change to the latter to have a separate src/foo/test.rs to conform the separate test file pattern.

Say you have

// lib.rs
#![deny(clippy::self_named_module_files)]
mod foo;

// foo.rs
#[test]
fn some_test() {}

to resolve this clippy lint, you would need to switch to

// lib.rs
#![deny(clippy::self_named_module_files)]
mod foo;

// foo/mod.rs
#[cfg(test)]
mod test;

// foo/test.rs
#[test]
fn some_test() {}

Compare that to

// lib.rs
#![deny(clippy::mod_module_files)]
mod foo;

// foo.rs
#[test]
fn some_test() {}

to resolve this clippy lint, you would need to switch to

// lib.rs
#![deny(clippy::self_named_module_files)]
mod foo;

// foo.rs
#[cfg(test)]
mod test;

// foo/test.rs
#[test]
fn some_test() {}

In either case, using this lint requires a lot more directories than before. When using mod.rs, the migration also requires moving your source.

Also, how does test_foo.rs work exactly?

You could take

// lib.rs
#![deny(clippy::self_named_module_files)]
mod foo;

// foo.rs
#[test]
fn some_test() {}

and switch it to

// lib.rs
#![deny(clippy::self_named_module_files)]
mod foo;
#[cfg(test)]
mod test_foo;

// foo.rs

// test_foo.rs
#[test]
fn some_test() {}

Doing so requires everything you want to test in foo.rs to be pub(super) at least.