test-group 1.0.0

Organize tests into groups with macros for filtering in nextest
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84

<div align="center">
  <h1>test-group</h1>
  <p>
    <strong>Organize Rust tests into groups for filtering in nextest</strong>
  </p>
  <p>

[![Crates.io](https://img.shields.io/crates/v/test-group.svg?style=for-the-badge)](https://crates.io/crates/test-group)
[![CI](https://img.shields.io/github/actions/workflow/status/sergiimk/test-group/build.yaml?logo=githubactions&label=CI&logoColor=white&style=for-the-badge&branch=master)](https://github.com/sergiimk/test-group/actions)
[![Dependencies](https://deps.rs/repo/github/sergiimk/test-group/status.svg?&style=for-the-badge)](https://deps.rs/repo/github/sergiimk/test-group)

  </p>
</div>

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](https://github.com/nextest-rs/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 test_heavy_stuff() {
  // ...
}
```

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 test_heavy_stuff() {
      // ...
    }
  }
}
```

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.