CodeVetter
← All unpacks
CodeVetter · Repo Unpack evidence

pytest-dev/pytest

Scanned commit 2887015cad dated 2026-09-29 — last upstream commit. Generated by codevetter 1.15.0 on 2026-10-02.

github.com/pytest-dev/pytest ↗ · 705 files · 5.3 MB

Deep analysis by cli:codex via the codex CLI on 2026-10-02 (372s) — every claim below links to its cited source files. Source inspection; upstream code and tests were not executed.

Overview

pytest is a Python 3.10+ testing framework for application and library developers, exposed through the pytest CLI, python -m pytest, and pytest.main(). Its implementation organizes configuration, discovery, fixtures, execution, and reporting around plugin hooks, allowing built-in behavior and third-party extensions to share the same contracts. Distinctive capabilities include rewritten assertion diagnostics, scoped fixture dependency management, phase-specific reports, and persistent failure history. This brief examines commit 2887015cade4757385308e7a7d8083557fc637e2 through read-only source inspection; it does not establish runtime correctness.

System map

The runtime is a Python library and command-line test runner distributed as a package. Public APIs are collected in pytest, while most implementation lives in _pytest modules registered as plugins. Config, Session, fixture definitions, and report consumers own different stages of a run. Packaging, documentation hosting, release automation, and maintenance jobs form separate operational boundaries.

Feature catalog

The primary user experience is selecting tests, discovering executable items, and receiving diagnostic reports. Fixtures and parametrization support reusable resources and generated test cases. Built-in integrations cover unittest, doctests, capture, logging, subtests, and machine-readable output. This catalog groups inspected capabilities into eight areas; it is bounded rather than an exhaustive listing of every CLI option.

Data flow

Arguments, environment options, configuration files, and plugins feed a mutable Config. Collection turns selected paths and node identifiers into Session items, and fixtures resolve those items' dependencies into function arguments. Runtime hooks produce reports containing outcomes and captured output. Report consumers render terminal output, serialize XML, and update cross-session failure state.

Behavior traces

Three principal flows were followed end-to-end: startup into session dispatch, Python test collection and execution, and failure-history persistence into a later selection. Additional branches show assertion-cache loading, fixture teardown, XML output, and stepwise interruption. These traces describe default implementations; hook replacements and wrappers can change behavior. Error and worker conditions are retained where they affect execution order.

Testing signals

Tests and CI were inspected, not executed; test existence is not a passing result. The repository tests pytest using pytest itself, including generated test projects through Pytester. Inspected cases exercise lifecycle reports, fixtures, assertion transforms, configuration, and cache boundaries. CI defines cross-platform and integration environments, but exclusions, disabled checks, and allowed failures limit what its configuration alone establishes.

Risk map

The following are source observations and explicitly labeled hypotheses, not confirmed vulnerabilities. pytest intentionally imports and executes selected tests, plugins, and conftests in the invoking process. Filesystem boundaries include configurable cache directories, temporary roots, bytecode caches, and report destinations. Lifecycle and compatibility changes have a broad impact because plugins share internal execution and reporting hooks.

Extension points

pytest exposes explicit plugin contracts for nearly every stage of its lifecycle. Extensions can register options, supply collectors, generate parameters, replace execution, and consume or transform reports. Fixtures and typed stashes provide resource and state extension mechanisms. Configuration loaders and the public re-export module are additional integration boundaries that require compatibility review.

Contributor handoff

Tests and CI were inspected, not executed, and the investigation is bounded rather than exhaustive. Future changes should begin with the public API, configuration lifecycle, and the specific plugin module involved. Lifecycle cleanup, configuration precedence, worker conditions, and downstream plugin compatibility are concrete review boundaries. Execution commands below are repository-documented follow-up checks for an authorized implementation session, not results from this investigation.

Languages

LanguageFilesShare of source
Python27499%
YAML17docs/config
Markdown6docs/config
JSON2docs/config
TOML21%
CSS1docs/config
HTML1docs/config

Start reading here

Probable source entrypoint: pyproject.toml — inferred from the directory tree and manifest, not the upstream docs.

Source roots

src/ (83 files)

Repository structure

Top-level pathFiles
doc/302
testing/179
src/83
changelog/83
.github/18
scripts/10
bench/7
extra/1

Package

pyproject.toml — Miscellaneous internal changes vsrc/_pytest/_version.py, 0 declared dependencies.

CI & config entrypoints

Structural health signals

Average score 7.3/10 across 96 analyzed source files; 15 hotspots surfaced.

These are deterministic review leads — size, churn, and structural signals — not proof of a bug in this project.

Recent history