pytest principles

This commit is contained in:
John Lancaster
2026-06-22 07:59:18 -05:00
parent ab53c239bf
commit ea5450f6cb
+13 -6
View File
@@ -16,9 +16,9 @@ x-personal-mcp:
- resource://skills/pytesting/document - resource://skills/pytesting/document
--- ---
# Pytest Scaffolding # Pytesting
This skill is a collection of best-practice references and source-documentation links for building and maintaining pytest suites. This skill is a collection of preferences and links to source documentation for building and maintaining pytest suites.
Use it to quickly find the right guidance for: Use it to quickly find the right guidance for:
1. Baseline pytest structure and marker strategy. 1. Baseline pytest structure and marker strategy.
@@ -67,7 +67,16 @@ Always consult [naming-and-organization.md](./references/naming-and-organization
3. The request mentions conventions, readability, hierarchy, or discoverability. 3. The request mentions conventions, readability, hierarchy, or discoverability.
4. The task introduces parametrization where case naming affects failure readability. 4. The task introduces parametrization where case naming affects failure readability.
## Baseline Best Practices ## Guiding Principles
These principles are abstract, but are the highest priority to follow.
- Much of testing is very well-trodden. In general, tests should follow whatever conventions there are.
- Tests will be run very frequently, so it's important that they run quickly and deterministically.
- When tests fail, it should be easy to determine what failed and fix it.
- Always be on guard against tests that are tautological. Every test should provide specific value by capturing something about the intent of the program.
## Pytest Best Practices
These are stable defaults regardless of stack: These are stable defaults regardless of stack:
@@ -86,9 +95,7 @@ These are stable defaults regardless of stack:
## Universal Test Double Policy (Repo-Local Placement) ## Universal Test Double Policy (Repo-Local Placement)
Treat this policy as universal guidance for test authoring, while it is documented in this repository-local skill file for now. To avoid over-using monkeypatching, mocks, fakes, etc, apply this policy whenever a test change introduces one of them:
Apply this policy whenever a test change introduces a fake collaborator or patched behavior:
1. Attempt a real-input, real-object test design first. 1. Attempt a real-input, real-object test design first.
2. If that approach is impractical, explain why and request user confirmation before adding monkeypatching, mocks, or fakes. 2. If that approach is impractical, explain why and request user confirmation before adding monkeypatching, mocks, or fakes.