From 57347077a92e3f512de8d9ee8134e0e10cfd94ec Mon Sep 17 00:00:00 2001
From: John Lancaster <32917998+jsl12@users.noreply.github.com>
Date: Sun, 21 Jun 2026 15:36:31 -0500
Subject: [PATCH] better pytest

---
 docs/skills/pytest-scaffolding/SKILL.md | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/docs/skills/pytest-scaffolding/SKILL.md b/docs/skills/pytest-scaffolding/SKILL.md
index f4a800f..4bb5831 100644
--- a/docs/skills/pytest-scaffolding/SKILL.md
+++ b/docs/skills/pytest-scaffolding/SKILL.md
@@ -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