tdd-workflow — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited tdd-workflow (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.
In test-driven development the test comes before the code. You describe the behavior you want as an executable expectation, watch it fail, then write just enough to satisfy it. The test becomes the specification, and a passing suite becomes the proof.
┌─────────────────────────────────────────────┐
│ RED write a test; run it; watch it fail │
│ ↓ │
│ GREEN write the least code that passes it │
│ ↓ │
│ REFACTOR tidy up while every test stays green│
│ ↓ │
└──── repeat for the next behavior ─────────────┘Three constraints keep the loop honest:
Express what the code should do, never how it does it.
| Aim at | Example name |
|---|---|
| Core behavior | adds two positive numbers |
| Boundaries | returns zero for an empty list |
| Failure modes | raises on a negative quantity |
Ground rules: the test must fail before you write any implementation, its name should read as a sentence about behavior, and each test should pin down a single idea.
# RED — this fails because cart_total does not exist yet
def test_cart_total_sums_line_items():
cart = Cart(items=[Item(price=300), Item(price=150)])
assert cart.total() == 450Write the plainest thing that turns the bar green. No speculative features, no tuning.
| Principle | What it means here |
|---|---|
| Avoid speculation | If a test does not demand it, do not build it |
| Plainest solution | The most obvious code that satisfies the assertion |
| Defer performance | Make it correct now; make it fast later, if measured |
# GREEN — just enough to satisfy the test
class Cart:
def __init__(self, items):
self.items = items
def total(self):
return sum(item.price for item in self.items)Now that the test guards behavior, reshape the code without changing what it does.
| Target | Move |
|---|---|
| Repetition | Pull shared logic into one place |
| Murky names | Rename for intent |
| Awkward structure | Reorganize for clarity |
| Tangled logic | Simplify the flow |
Refactor in small steps, keep the suite green throughout, and commit once it settles.
A readable test separates setup, action, and check:
def test_discount_applies_to_subtotal():
cart = Cart(items=[Item(price=1000)]) # set up the inputs
cart.apply_discount(0.10) # exercise the behavior
assert cart.total() == 900 # check the result| Situation | Value of leading with tests |
|---|---|
| New feature | High — the test defines "done" |
| Bug fix | High — reproduce it as a failing test first |
| Intricate logic | High — correctness is hard to eyeball |
| Open-ended exploration | Low — spike first, then come back and test |
| Pure visual layout | Low — tests are a poor fit |
| Trap | Practice instead |
|---|---|
| Skipping RED and writing code first | Always see the test fail before you fix it |
| Writing tests after the fact | Let the test lead the implementation |
| Gold-plating the first pass | Keep it minimal until a test asks for more |
| Cramming many assertions in | One behavior per test |
| Asserting on internals | Assert on observable behavior |
A closing reminder: if you cannot write the test, you do not yet understand the requirement.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.