python-testinglisted

# python-testing ## Purpose Add pytest coverage that fits the repository it lands in. Most test damage comes from writing tests before reading the ones already there: a second fixture style, a parallel directory layout, or a mocking convention the project deliberately avoids. This skill orders the work as discover, decide, write, verify. ## When to use this - A Python change adds behavior, fixes a bug, or changes a public interface. - A change touches security-relevant logic (input validation, authorization, crypto, secrets). - Deciding where a test belongs in a repository whose layout is unfamiliar. ## When NOT to use this - Non-Python changes. - Repositories that use a test framework other than pytest. Follow what is there instead; do not introduce pytest alongside an existing framework. ## Steps 1. **Discover the existing layout before writing anything.** Do not assume a structure. - Find the test root: `tests/`, `test/`, alongside the source as `test_*.py`, or inside the package. Check `pyproject.toml`, `pytest.ini`, `setup.cfg`, and `tox.ini` for `testpaths`, `python_files`, `addopts`, and marker definitions. - Read two or three existing tests near the code being changed. Note the naming pattern, how fixtures are shared (`conftest.py`, factory functions, plain constructors), whether parametrization is used, and what the project mocks versus exercises for real. - Check for markers (`slow`, `integration`, `network`) and what the defau