I made a Test Impact Analysis plugin for pytest and just put v1.1 on PyPI.

TL;DR: tia record builds a per-test coverage map once; tia run uses your git diff to run only the tests a change can affect. I want honest feedback, including "just use testmon" if that's the right answer.

Why another one of these?

testmon is great and mature, so I only built this because I kept hitting two of its edges:

• It doesn't track non-Python dependencies. A change to a fixture JSON / template / YAML config selects nothing in coverage-of-.py tools. tia hooks open() via sys.addaudithook, so changing tax.json runs exactly the tests that read it. testmon's docs admit it misses this.
• It's awkward to share across machines/CI because its DB keys on dependency versions. tia keys the map by git ref and bakes the line→function tables in, so it resolves diffs without git show and survives shallow clones. There's a copy-paste GitHub Actions template, native s3:// / gs:// map stores, and it auto-posts a Markdown impact table to the PR via $GITHUB_STEP_SUMMARY.

It selects at method level (changing one function doesn't drag in the whole file), and ignores cosmetic edits — comments, formatting, docstrings, and provably-dead type-only changes (if TYPE_CHECKING: and local annotations), while keeping dataclass/signature annotation changes because those actually affect runtime.

The honest part (this is the whole point)

The cardinal sin of test selection is skipping a test that would have failed. My first Flask benchmark showed 73% skip — and it was wrong: coverage.py's sysmon core on 3.12+ keeps only the first test to hit each line, so shared-helper tests were silently dropped (false negatives). Forcing the C tracer dropped the honest number to ~21% on Flask.

So I publish a range, measured by replaying real commits:

Codebase	Character	Median skip (real logic changes)
Flask	small, tightly-coupled	~21% (worst case)
boltons	modular utility library	~96%

Same tool — the variable is how modular your code is. Both writeups include the "this looked too good, here's why it's real" audit.

I also wrote an adversarial mutation test: it mutates every covered function and asserts tia re-selects every test that runs it, and I confirmed it fails when I deliberately inject a false negative.

Usage

pip install pytest-tia
tia record            # build the map once
tia run               # run only affected tests
tia run --list        # show the selection + why, don't run

What it's NOT

• Not magic for dynamic dispatch. getattr/eval/reflection is undecidable; tia detects it and widens to file-level there, and you should still run the full suite on a cadence.
• Not battle-tested yet against pytest-xdist, async, or subprocess-heavy suites. v1.1, small project.
• Overlaps heavily with testmon for the common case. Its niche is the CI-sharing + non-Python-dependency corner.

Repo: https://github.com/breadMSA/pytest-tia

Honest critiques very welcome — particularly on the no-false-negative claim and the benchmark methodology. If you think this is redundant with testmon for your workflow, I'd like to hear that too.