A pytest plugin that measures test reliability instead of hiding failures. Unlike retry plugins that immediately rerun failed tests to make builds pass, it preserves the original execution, reruns failures in isolated subprocesses, and classifies every test as PASS, BROKEN, or FLAKY.

• Deliberate rerun strategy — completes the full initial run first, then reruns only the failures in isolated pytest subprocesses, appending each attempt to a preserved execution history.
• Classification, not suppression — a failed test that later passes is FLAKY; one that never passes is BROKEN — so intermittent failures are surfaced explicitly rather than hidden by retries.
• CI-consumable output — a versioned JSON report with per-attempt history plus a console summary, designed to plug into pipelines; linted and type-checked (Ruff, mypy) with GitHub Actions CI.

A generic API test-automation framework built around a layered test pyramid and a staged CI strategy — smoke, nightly, and release pipelines with progressively stricter quality gates. A FastAPI service stands in as the system under test.

• Three-tier quality gates — a fast smoke pipeline on every push, a nightly pipeline running full regression, contract, k6 performance, and coverage, and a release pipeline that blocks tagging until every gate passes.
• Layered test pyramid — unit (mocked), integration (CRUD against a live API), contract (OpenAPI validation via Schemathesis), and end-to-end journeys, with pytest markers for selective, parallel-safe runs.
• Failure diagnostics — captures request method, URL, payload, and response on any failed test, surfaced through JUnit XML for CI and Allure for human investigation.

A payment-correctness testbed that reproduces one of the most common distributed-systems failures — the customer is charged, but the application never records the payment. Instead of asserting HTTP responses, every test verifies the PostgreSQL ledger, where financial truth actually lives.

• Deterministic fake gateway — a test double (not the system under test) that makes rare production failures repeatable: successful charges, idempotent charging, and intentionally lost confirmations (504), with inspection endpoints.
• Flagship dual-write scenario — the customer is charged, the API returns 504, and the order stays pending with no payment row; a reconciler then uses the durable idempotency key to query the gateway, writes the missing payment, and marks the order paid — with no second charge.
• Ledger-truth assertions — integration tests verify order state, payment rows, and charge count in PostgreSQL rather than trusting the API, covering idempotency and concurrent duplicate requests.