|
| 1 | +--- |
| 2 | +name: usethis-python-test-affected-find |
| 3 | +description: Identify tests that are potentially affected by code changes, to catch regressions before CI |
| 4 | +compatibility: usethis, Python, pytest |
| 5 | +license: MIT |
| 6 | +metadata: |
| 7 | + version: "1.0" |
| 8 | +--- |
| 9 | + |
| 10 | +# Finding Potentially Affected Tests |
| 11 | + |
| 12 | +## Procedure |
| 13 | + |
| 14 | +After making code changes and before pushing, identify and run tests that could be affected: |
| 15 | + |
| 16 | +1. Determine which source modules you changed. |
| 17 | +2. Run the directly corresponding test modules for those source modules. |
| 18 | +3. Apply the domain-specific rules below to identify additional tests that are indirectly affected. |
| 19 | +4. Run all identified tests locally to catch regressions before CI. |
| 20 | + |
| 21 | +## General principles |
| 22 | + |
| 23 | +### Trace callers, not just callees |
| 24 | + |
| 25 | +When you change a function or class, the most commonly missed regressions come from **callers** of that code, not the code itself. Search for usages of the changed function or class across the codebase and identify tests for those callers. |
| 26 | + |
| 27 | +### Look for integration-style tests |
| 28 | + |
| 29 | +Changes to internal logic often break higher-level tests that exercise end-to-end workflows. After identifying unit tests, also search for integration or interface-level tests that exercise the same functionality through the CLI or public API. |
| 30 | + |
| 31 | +### Check tests that assert exact output |
| 32 | + |
| 33 | +Tests that assert exact string output (e.g. CLI output snapshots, formatted messages) are especially fragile to changes in underlying logic. If your change could alter the content, ordering, or formatting of output, find tests that compare against expected output strings and run them. |
| 34 | + |
| 35 | +## Domain-specific rules |
| 36 | + |
| 37 | +### Rule management logic |
| 38 | + |
| 39 | +Any change to how linter rules are selected, ignored, reconciled, or merged — including changes to rule configuration classes, rule reconciliation helpers, or rule-related methods on tool base classes — can affect the CLI output verified by integration tests. |
| 40 | + |
| 41 | +**Always run the `test_readme_example` tests.** These tests verify that CLI commands produce the exact output shown in the README. They are sensitive to any change in rule management because the README examples include specific rule selections and ignores. Search for test methods named `test_readme_example` in the test suite and run them. |
| 42 | + |
| 43 | +### Tool configuration changes |
| 44 | + |
| 45 | +When modifying how a tool writes or reads its configuration (e.g. pyproject.toml sections, config file generation), run both: |
| 46 | + |
| 47 | +- The tool's own test module. |
| 48 | +- Any tests that verify CLI output for that tool, since configuration changes often alter the messages shown to users. |
| 49 | + |
| 50 | +### File I/O and serialization changes |
| 51 | + |
| 52 | +Changes to file reading, writing, or serialization logic (e.g. TOML, YAML, INI handling) can affect any tool that uses that file format. Identify which tools depend on the changed file format and run their tests. |
0 commit comments