Practice Toolkit
The Practice Toolkit is a set of tool cards: one page per command-line tool that the handbook’s methods rely on, read with a terminal open. A card says what the tool is for, how to run it, how to read its output, which mistakes are common, and how to run it in CI. It teaches the tool, not the method; each card links to the method pages that explain why.
| Stage | Tool card | The question it answers |
|---|---|---|
| Project and pipeline | Poetry and uv | Which dependencies, in which versions, does this project run with? |
| GitHub Actions | Does every push pass the same checks? | |
| Podman and Docker | Does the service run the same way on every machine? | |
| Testing | pytest | Do the examples I wrote still pass? |
| Coverage.py and pytest-cov | Which lines and branches did the tests execute? | |
| Hypothesis | Does a rule hold for inputs I did not think of? | |
| mutmut | Would my tests notice if the code were wrong? | |
| Static and security checks | flake8 and Ruff | Does the code follow the style rules, and is any function too complex? |
| Radon | How complex and how maintainable is each function and file? | |
| mypy | Do the types fit together? | |
| Bandit and pip-audit | Does the code or one of its dependencies contain a known security weakness? | |
| Trivy | Does the container image carry known vulnerabilities or an unsafe configuration? | |
| Generated inputs and tests | Atheris | Does any input make the code fail unexpectedly? |
| CrossHair | Can any input break this contract, or tell two versions apart? | |
| Pynguin | Which tests follow from the code alone, and what do they miss? | |
| Performance | Locust | How do response time and failures behave under load? |
| Prometheus | What did the service itself measure while under load? | |
| Combinatorial | PICT | Which few tests cover every pair of input values? |
| ACTS | The same, with NIST’s generator and its higher strengths |
The table follows the tools’ place in a project, not a reading order: GitHub Actions needs the tools from the testing and static-check cards, and the container, Trivy and Prometheus cards need the service printed on the Locust card. Locally, Atheris and Pynguin run in containers.
Every card uses one small example project: a parking-fee calculator in Python. (Constructed example.) Each card prints the files it adds, so the project grows as you go; counts such as “files checked” change with it.
parking/
├── pyproject.toml poetry.lock .flake8 .github/workflows/ci.yml
├── locustfile.py machine.txt machine_acts.txt prometheus.yml
├── Containerfile Containerfile.fixed Containerfile.monitor
├── Containerfile.fuzz Containerfile.pynguin
├── src/parking/ fee.py receipt.py lookup.py export.py app.py monitored.py
│ ticket.py contracts.py fee_v2.py
├── fuzz/ fuzz_ticket.py
└── tests/ test_fee.py test_fee_props.py
The tools also create files (mutants/, .hypothesis/, htmlcov/, results_*.csv, machine.tsv, machine.csv, parking.tar, fuzz/crashes/, generated/); keep them out of version control.
Each card states the tool version it was run with, and its output comes from that run (the ACTS run is still to be added). Tools change, so compare versions before trusting a flag or a configuration key.
Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.