Cargo's built-in test runner does not support grouping tests, which can be a problem when some of your tests are reasource-intensive and you don't want to run them all at once. Nextest solves this problem by allowing you to define test groups using filter expressions in a config file and limit concurrently.

This works, but you may find yourself: - Having very complex filter expressions that often go out-of-sync with code - Or having a special module hierarchy for your tests, separating tests into modules like heavy, dockerized etc. - this is not ideal because tests for the same component may now end up in different files, based on how "heavy" they are.

This tiny crate lets you group tests in code like so:

```rust

[test_group::group(setup, heavy)]

[test]

fn test_setup() { // ... }

[test_group::group(heavy)]

[test]

async fn testheavystuff() { // ... } ```

This will result in a code like this:

```rust mod g3d6f { use super::; mod setup { use super::; mod heavy { use super::*; #[test] fn test_setup() { // ... } } } }

mod g64dc { use super::; mod heavy { use super::; #[test] async fn testheavystuff() { // ... } } } ```

So that these tests will appear in nextest as: - g3d6f::setup::heavy::test_setup - g64dc::heavy::test_heavy_stuff

Allowing you to filter tests by group in your .config/nextest.toml as such:

toml [[profile.default.overrides]] filter = 'test(::heavy)' max-threads = 1

Or when running as:

sh cargo nextest run -E 'test(::setup::)'

Note: The extra modules like g3d6f are generated by the macro to avoid module name collisions, as unlike impl bocks you cannot have more than one mod X {} in one file. The names are based on a SHA hash of the test content to be stable but unique-ish.