What this prompt does
This prompt asks the AI to design a comprehensive Python test strategy and suite rather than a handful of ad-hoc tests. It specifies eight deliverables: a pytest conftest.py with shared fixtures, unit tests for [modules] using [mock_library], integration tests against [integration_targets], parametrized edge and boundary cases, factory classes via [factory_library], pytest-benchmark performance tests, coverage config targeting [coverage]%, and a CI pipeline for [ci_platform] — all following Arrange-Act-Assert, with a test README.
The structure works because it treats testing as a system, not a chore. The [project_type] variable frames what's under test, [modules] scopes the unit coverage, and [integration_targets] plus [mock_library] draw the line between what's mocked and what's hit for real. Factories from [factory_library] make test data cheap, parametrization covers edge cases systematically, and the [ci_platform] config wires it all into your pipeline so the suite runs on every push.
When to use it
- You're establishing a test strategy for a Python project from scratch or stabilizing a shaky one.
- You want shared fixtures and factories so writing new tests is cheap, not repetitive.
- You need a clear split between mocked unit tests and real integration tests.
- You want parametrized edge-case coverage instead of a few happy-path tests.
- You need the suite wired into CI on
[ci_platform]with a coverage target.
Example output
Expect a structured test suite: a conftest.py with shared fixtures, unit tests for [modules] using [mock_library], integration tests hitting [integration_targets], parametrized boundary cases, [factory_library] factories for test data, pytest-benchmark performance tests, a coverage configuration aimed at [coverage]%, and a [ci_platform] pipeline config. A README explains the strategy and the Arrange-Act-Assert convention — a coherent testing system rather than scattered test files.
Pro tips
- Scope
[modules]to what carries real logic; testing trivial getters inflates coverage without adding safety. - Be precise about
[integration_targets]— anything not listed there should be mocked with[mock_library], and vice versa. - Treat
[coverage]as a target, not a finish line (the default 90 is high) — verify tests assert behavior, not just execute lines. - Lean on
[factory_library]for test data; check for existing factory states before writing setup by hand. - Match
[ci_platform]to where you actually run CI so the generated pipeline config drops in without rework. - Run the suite locally before committing the CI config, so a green pipeline reflects real passing tests, not a misconfigured runner.
