Python testing

Objective

Maintain confidence in observable behavior at the appropriate architectural boundary. Treat testing as part of every behavior change, not as a final step that consists of adding a few unit tests. Respect the repository's established test architecture while correcting missing coverage when necessary.

1. Discover the test architecture before writing tests

Before implementing or changing tests:

1. Inspect the repository structure and existing test conventions. Search beyond directories named tests: include .feature files, BDD step definitions, integration/system/end-to-end suites, contract tests, fixtures, test utilities, and relevant CI/test configuration.
2. Identify the test levels actually present, what each considers its system under test (SUT), where execution enters that SUT, and how its outcome is observed.
3. Trace which existing behaviors and contracts the proposed code change affects. Locate existing scenarios, parameter tables, and regression tests that should be extended.
4. Identify missing coverage even when the changed module/class/function has no existing test file. Absence of a precedent is not a reason to omit a test.
5. Identify the owning production module/class for each unit-level behavior to be tested, and locate its corresponding test module (or the appropriate place to create one). Do not organize tests by the feature/change that prompted them.
6. Use existing conventions and frameworks where practical; don't introduce a competing structure by default.

Do not equate the test architecture with only the test files adjacent to the changed code.