pytest support

Detection#

pytest projects are detected from pytest.ini, pytest settings in pyproject.toml, setup.cfg, or tox.ini, and conventional Python test-file patterns such as test_*.py and *_test.py.

Detection also works for package-level test folders in monorepos. If Python tests sit beside JavaScript or Java test suites, Test Chronicle keeps pytest activity separate through framework labels and filters.

Parsed information#

Test Chronicle records test_ functions, async test functions, file paths, line numbers, class groupings, pytest markers, and @pytest.mark.parametrize patterns.

Markers are useful search and review context. They can expose slow, integration, smoke, or custom category labels when teams use markers consistently. Parameterised decorators are tracked as source patterns, so the dashboard reflects committed definitions rather than every runtime case.

Limits and configuration#

Dynamically generated pytest cases and plugin-expanded runtime cases are not expanded unless they are visible as source definitions. Generated files, vendored examples, and archived tests should be excluded from discovery when they are not part of the maintained suite.

Use testing classification to separate unit, integration, and end-to-end pytest folders. That keeps Health Score breadth and testing-type filters aligned with the repository layout.

Repository history#

Parsed pytest definitions are compared across Git history to identify additions, deletions, renames, and maintenance changes with commit, contributor, date, and framework context.

This gives Python teams a searchable route from a changed test back to the commit and author that changed it. It also helps reviewers distinguish active pytest maintenance from broad source churn during package restructuring.