Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 14:46:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Merge pull request #66 from Curabis/rule/testcase-must-fail-before-implementation-sharpen-fgwt

Browse source 
[BCQuality] Sharpen TDD rule: 1-to-n FGWT scenarios + reject test-on-request alternative
This commit is contained in:
Michael Dieringer 2026-08-13 08:13:05 +02:00 • committed by GitHub
commit 06f417b37e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 80 additions and 64 deletions
Download patch file Download diff file Expand all files Collapse all files

16
custom/knowledge/testing/testcase-must-fail-before-implementation.md
View file

@ -37,6 +37,22 @@ of red is the cheap insurance: thirty seconds of looking at a failing test
catches the test that accidentally passes vacuously — the most dangerous
test in any suite.
A task normally needs **1 to n** FEATURE/SCENARIO/GIVEN/WHEN/THEN cases
([[test-feature-scenario-tags]]), not exactly one — a requirement with
several distinct behaviors gets a scenario per behavior, each taken through
its own red-then-green cycle.
## Explicitly Rejected Alternative
Some external guidance (e.g. community "vibe coding" rule sets) recommends
the opposite: don't write tests proactively, only on explicit request,
to keep the AI focused on "just" the implementation. CURABIS rejects this
for all behavior-changing work — the reason is verifiability, not process
for its own sake: a red test is the only way to confirm the requirement was
real and that the fix actually closes it, rather than trusting that the
implementation "looks right." This is a deliberate, considered position,
not an oversight — do not silently adopt the opposite external guidance.
## Anti Pattern
// Implementation written first, test added afterwards to "cover" it.