tdd — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited tdd (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Core principle: tests must verify behavior through public interfaces, not implementation details. The code may change completely; the tests should not.
Good tests are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_. A good test reads like a specification: "user can checkout with valid cart" immediately tells you which capability exists. Such tests survive refactorings because they are indifferent to internal structure.
Bad tests are coupled to implementation. They mock internal collaborators, test private methods, or verify state through external means (e.g. reaching directly into the database instead of using the interface). A red flag: the test breaks during a refactor even though behavior did not change. If renaming an internal function breaks the tests, those tests were testing implementation, not behavior.
For examples see tests.md; for the mocking guide see mocking.md.
Do NOT write all the tests first and then all the implementation. That is "horizontal slicing" — interpreting RED as "write all the tests" and GREEN as "write all the code".
This produces bad tests:
The right approach: vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned in the previous cycle. Because you have just written the code, you know exactly which behavior matters and how to verify it.
WRONG (horizontal):
RED: test1, test2, test3, test4, test5
GREEN: impl1, impl2, impl3, impl4, impl5
RIGHT (vertical):
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
RED→GREEN: test3→impl3
...When exploring the codebase, use the project's domain glossary so that test names and interface vocabulary match the project's language, and follow the ADRs in the area you are modifying.
Before writing code:
Ask: "What should the public interface be? Which behaviors are most important to test?"
You cannot test everything. Clarify with the user which behaviors matter most. Focus testing on critical paths and complex logic, not every possible edge case.
Write ONE test that confirms ONE fact about the system:
RED: Write test for first behavior → test fails
GREEN: Write minimal code to pass → test passesThis is your tracer bullet — it proves the path works end-to-end.
For each remaining behavior:
RED: Write next test → fails
GREEN: Minimal code to pass → passesRules:
Once all tests pass, look for refactor candidates:
Never refactor on RED. Get to GREEN first.
[ ] Test describes behavior, not implementation
[ ] Test uses public interface only
[ ] Test would survive internal refactor
[ ] Code is minimal for this test
[ ] No speculative features added~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.