scrut
| Crates.io | scrut |
| lib.rs | scrut |
| version | |
| source | src |
| created_at | 2022-05-20 13:08:06.51399 |
| updated_at | 2025-01-17 13:30:19.760787 |
| description | A simple and powerful test framework for CLI applications |
| homepage | |
| repository | https://github.com/facebookincubator/scrut |
| max_upload_size | |
| id | 590234 |
| Cargo.toml error: | TOML parse error at line 17, column 1 | 17 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
| size | 0 |
Martin (uepoch)
documentation
README
Scrut
Scrut is a testing toolkit for CLI applications. A tool to scrutinize terminal programs without fuzz. Heavily inspired by Cram.
Why though?
Testing CLIs is complicated. Sure, you can (should!) write unit tests, as for any other software application, but they will (should!) only address your business logic and not test dependencies towards or interaction with the environment (command line input, environment variables, external APIs, etc).
What constitutes a CLI is not obvious or standardized. Some are small shell script, that consists of only a handful lines of code, which automate a thing that you are too lazy to do by hand more than once. Others are build upon tens of thousands of lines of code and feature multiple sub-commands that solve a range of related and complex problems. Often those large applications start out as small shell scripts and then evolve over time. You can call a program a CLI as long as it is intended to be executed from the shell.
A testing framework for CLIs should address all of that.
Scrut is a tool in the functional / integration / end-2-end / blackbox testing space. Tests are written in a flexible syntax that can be used to prove the behavior of any CLI - however complex and in whatever language (Rust, Java, Ruby, C++, Typescript, ...) they are written in.
Scrut aims to be
- Low Threshold, so that it's easy to learn and the entry barrier is very low (if you can execute commands on the terminal, you should be able to write a test)
- Low Effort, so that writing tests for even small CLI scripts is not (too) much overhead
- Low Maintenance, so that keeping tests around and up2date is not a painful chore
- Readable, so that tests can provide additional value to the reader as documentation (of the thing that is tested)
How then?
The scrut command line application executes tests of CLIs that are persisted in Markdown (.md) or Cram (.t) files.
A very simple test looks like this:
# Smoke test of the ACME CLI
This file contains a smoke test for the `acme` command line tool.
If it fails then things are seriously broken.
## Print version
```scrut
$ acme --version > /dev/null
```
To start using Scrut, see the Tutorial page for a walkthrough of Scrut use from start to end.