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

better pytest

Browse Source
This commit is contained in:
John Lancaster
2026-06-21 15:36:31 -05:00
parent 7fec3a4337
commit 57347077a9
1 changed files with 8 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/skills/pytest-scaffolding/SKILL.md
+8 -3
View File
@@ -73,8 +73,12 @@ These are stable defaults regardless of stack:
4. Register markers up front (`unit`, `integration`, `smoke`, `slow`, `external`) and keep strict marker checks enabled.
5. Separate fast feedback (`-m unit`) from broader integration/external lanes.
6. Validate structure early with collection checks before expanding assertions.
7. Prefer behavior-first tests that exercise real code paths and concrete inputs over patching internals.
8. Use monkeypatching, mocks, and fakes extremely sparingly, only when no practical real-input alternative exists, and only after explicit user confirmation.
7. Keep test scope tight and count intentional; add tests only when each case protects a distinct behavior.
8. Start with the single core-intent behavior path, then add edge cases based on real risk.
9. Prefer parametrized tests for behavior variants instead of cloning near-identical test functions.
10. Reject low-signal assertions (for example `assert True` patterns) and avoid tests that only assert a mock was called.
11. Prefer behavior-first tests that exercise real code paths and concrete inputs over patching internals.
12. Use monkeypatching, mocks, and fakes extremely sparingly, only when no practical real-input alternative exists, and only after explicit user confirmation.
## Universal Test Double Policy (Repo-Local Placement)
@@ -85,7 +89,8 @@ Apply this policy whenever a test change introduces a fake collaborator or patch
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.
3. Keep any approved test double narrowly scoped and document the exact boundary it replaces.
4. Revisit approved test doubles when implementation seams improve so they can be removed.
4. Do not treat call-only verification as sufficient; pair any test double with assertions on observable behavior or outputs.
5. Revisit approved test doubles when implementation seams improve so they can be removed.
## Stack-Specific Guidance