blob: 59d45ce533e2f2e6c8bbdc57bdf1cbaebae67d3c (
plain)
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
|
# Arti CLI tests
This is a [`trycmd`]-based test suite for the arti CLI.
Each testable subcommand has a corresponding directory in `testcases`:
```
tests
├── cli_tests
│ ├── hsc.rs # hsc non-trycmd cli test
│ ├── main.rs
│ └── runner.rs # trycmd test runner
├── README.md
└── testcases
├── hsc
│ ├── help.stderr # expected stderr for the "help" test
│ ├── help.stdout # expected stdout for the "help" test
│ ├── help.toml # hsc "help" test
│ ├── hsc.in # test inputs and CWD
│ └── hsc.md # multiple hsc tests
├── hss # hss subcommand tests
│ ├── hss.in # test inputs and CWD
│ └── hss.md # multiple hss tests
└── ...
```
Each feature-dependent subcommand has a corresponding `<subcmd>-feature-missing`
test case, which tests that we output a hint about recompiling arti with the
necessary features (the feature-dependent tests are currently all skipped,
because we don't yet print helpful messages in such cases. See #1487).
The tests can be written as [`*.trycmd`/`*.md` files], or in [`toml` format].
The `*md`-based tests can double as documentation, so they are often preferable
over the `toml` ones.
See the [`trycmd`] docs for more information.
> Note: [`trycmd`] is currently limited in functionality, when it is not
> possible to write an exhaustive test suite using [`trycmd`] it is possible
> to use [`assert_cmd`], and write the test inside the `cli_tests`'
> submodule `hsc.rs` (another submodule `hss.rs` will be created in
> the future if needed).
### Debugging
You can pass `-F trycmd/debug` to `cargo test` to debug `trycmd`'s behavior.`
[`trycmd`]: https://docs.rs/trycmd/latest/trycmd/
[`assert_cmd`]: https://docs.rs/assert_cmd/latest/assert_cmd/
[`*.trycmd`/`*.md` files]: https://docs.rs/trycmd/latest/trycmd/#trycmd
[`toml` format]: https://docs.rs/trycmd/latest/trycmd/#toml
|
