maintaining-python-tests

Optimizes existing pytest and Django test suites while preserving behavior coverage.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill maintaining-python-tests
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: maintaining-python-tests
Source: https://github.com/PostHog/posthog-foss/tree/main/.agents/skills/maintaining-python-tests
Command: npx skills add https://github.com/PostHog/posthog-foss --skill maintaining-python-tests

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Python test suites grow slow and expensive over time, and naive optimization attempts often weaken coverage, break isolation, or fail to reduce actual CI wall time. This Skill provides a measurement-driven workflow for reducing test compute and maintenance burden without losing the regressions the suite exists to catch.

Core Features & Use Cases

  • Measured cost ranking: Rank tests, parameterized families, and pytest shards by observed CI span data (p50, p95, observed hours) instead of guessing from one slow local run.
  • Safe optimization patterns: Apply proven fixes such as sharing expensive immutable infrastructure, moving tests to cheaper levels, retiring expired migration tests, and replacing incidental snapshots with stronger assertions.
  • Post-merge verification: Compare equivalent master-branch CI windows to confirm whether testcase time, suite wall time, and ownership actually changed after a fix merges.
  • Use Case: A team's backend CI shard takes 40 minutes. Use this Skill to rank the slowest parameterized families from trace data, consolidate repeated database fixture setup while preserving per-case isolation, and verify the shard's wall time dropped on fresh master runs.

Quick Start

Ask the AI to investigate the slowest pytest suites in the repository and propose a measured optimization plan using this skill.

Frequently Asked Questions about maintaining-python-tests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I reduce pytest suite runtime in CI?

Rank tests by measured cost using CI trace spans (executions times duration, p50, p95, observed hours), then profile the cost center before changing code. Apply the smallest safe fix such as sharing expensive immutable infrastructure or moving tests to a cheaper level, and verify on fresh master runs.

How to speed up slow Django tests without losing coverage?

Prefer SimpleTestCase when no database access is needed and TestCase when transaction rollback suffices, reserving TransactionTestCase for committed-transaction behavior. Reduce repeated database setup with factories and immutable parent rows, but keep distinct behavior cases and prove isolation by running the class repeatedly.

When should I delete a migration test?

Delete a data-migration test only after explicit approval and when every supported environment applied the migration, the rollback window closed, and no supported upgrade starts from the old state. Keep the migration file itself and any tests for reusable backfill frameworks or runnable commands.

Why did my test optimization not reduce CI wall time?

Summed testcase time and suite wall time measure different work; a fixture change can move cost from call phases into one setup phase without changing the critical path. Compare equivalent master-branch windows for both metrics and check whether cost moved into setup, teardown, or another shard.

Can I share fixtures across pytest cases safely?

Share only expensive immutable infrastructure like workers, clients, or containers, never mutable state such as tenant rows, workflow IDs, or consumer offsets. Give each case unique identifiers, keep teardown at the same scope as setup, and run cases alone, together, and in different orders to prove isolation.

What should I use instead of this skill for flaky tests?

Use the fixing-flaky-tests skill when intermittent failure is the main problem, since it focuses on reproducing and fixing nondeterminism. This skill explicitly excludes flaky-test work and forbids sleeps, retries, or larger timeouts as performance fixes.