john/prompts
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

pytest principles

Browse Source
This commit is contained in:
John Lancaster
2026-06-22 07:59:18 -05:00
parent ab53c239bf
commit ea5450f6cb
1 changed files with 13 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/skills/pytesting/SKILL.md
+13 -6
View File
@@ -16,9 +16,9 @@ x-personal-mcp:
- 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:
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.
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:
@@ -86,9 +95,7 @@ These are stable defaults regardless of stack:
## 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.
Apply this policy whenever a test change introduces a fake collaborator or patched behavior:
To avoid over-using monkeypatching, mocks, fakes, etc, apply this policy whenever a test change introduces one of them:
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.