Tdd

Skill aizech/bernhard-zechmann-skills/skills/engineering/tdd

Test-driven development with red-green-refactor. Use when the user wants to build features or fix bugs test-first, or mentions unit, integration, or red-green-refactor tests.From its SKILL.md

Install

npx -y skills add aizech/bernhard-zechmann-skills --skill tdd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

1.9 KB, 372 tokens by cl100k_base, as published. Nobody here has run it

Test-Driven Development

Build features and fix bugs one vertical slice at a time, using tests as the feedback loop.

Core principle

Tests verify behavior through public interfaces, not implementation details. If you refactor and the test breaks without behavior changing, the test was wrong.

Anti-pattern: horizontal slices

Do not write all tests first, then all implementation. Write one test, make it pass, then repeat.

Wrong:  RED test1, test2, test3 -> GREEN impl1, impl2, impl3
Right:  RED test1 -> GREEN impl1 -> RED test2 -> GREEN impl2 -> ...

Workflow

1. Plan

Confirm the interface changes with the user.
Confirm which behaviors to test. You cannot test everything.
List behaviors as observable outcomes, not implementation steps.
Get user approval before writing code.

2. Tracer bullet

Write one test for one behavior. Watch it fail. Write the minimal code to make it pass.

3. Incremental loop

For each remaining behavior:

Write the next test.
Make it pass with minimal code.
Do not anticipate future tests.

4. Refactor

After all tests pass:

Extract duplication.
Deepen modules: small interface, deep implementation.
Run tests after each refactor step.

Never refactor while RED.

Checklist per cycle

Test describes behavior, not implementation.
Test uses the public interface.
Test would survive an internal refactor.
Code is minimal for this test.
No speculative features added.

Rules

Write tests before implementation for new behavior.
Use type hints and clear names.
Keep functions small and single-purpose.
Fail fast with clear error messages.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.