Merged PR #24: tooling + architecture-upkeep rules, tool tests Co-authored-by: Zwitschi <zwitschi82@gmail.com>
27 lines
1.3 KiB
Markdown
27 lines
1.3 KiB
Markdown
# Tooling tests
|
|
|
|
Standard-library `unittest` tests for the host-side tools in `Tools/`. They never start Blender, Unreal, or the game; anything that needs those processes is verified by the tool itself and recorded in `Docs/release-checks.md` instead.
|
|
|
|
Run from the repository root:
|
|
|
|
```bash
|
|
python3 -m pip install -r requirements-tools.txt
|
|
python3 -m unittest discover -s Tools/tests -t Tools -p 'test_*.py'
|
|
```
|
|
|
|
The `-t Tools` top-level directory is required: the tests import the tool modules by their plain names (`import input_emulation`), which is why `Tools/tests/` carries an `__init__.py`.
|
|
|
|
Individual test:
|
|
|
|
```bash
|
|
python3 -m unittest Tools.tests.test_input_emulation -v
|
|
```
|
|
|
|
## What belongs here
|
|
|
|
Test the **pure** parts — argument parsing, key/coordinate encoding, geometry maths, licence gating, report formatting, decision classification. Network, Blender and Unreal calls stay out: a test that needs a paid API, a display, or an engine process is a manual check, not a unit test.
|
|
|
|
When a tool's logic is buried in `main()`, extract it into a function so it can be tested directly. That is a tooling improvement, not test scaffolding.
|
|
|
|
Geo (`Geo/tools/`) and Blender (`Art/blender/*/`) builders are tested the same way once their pure parts are extracted; note the module path in the test.
|