- Home
- Skills
- Copyleftdev
- Sk1llz
- Beck Tdd
beck-tdd_skill
- Python
3
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill copyleftdev/sk1llz --skill beck-tdd- SKILL.md15.4 KB
Overview
This skill teaches and enforces Kent Beck’s Test-Driven Development (TDD) style for Python development: red-green-refactor, tests-first design, baby steps, and emergent architecture. It guides developers to write a failing test, make it pass with the simplest code, then refactor continuously so design emerges from working examples. Use it to build disciplined, maintainable code and to gain confidence when changing behavior.
How this skill works
The skill inspects development workflows and suggests concrete TDD steps: what test to write next, how to keep tests fast and focused, and which refactors to apply after green. It provides patterns and examples (Arrange-Act-Assert, triangulation, fake/stub/spy usage) and practical rules (commit after each green-refactor cycle, avoid refactoring on red). Recommendations are concise, actionable, and tied to Python idioms and test structure.
When to use it
- Starting a new feature to design interfaces before implementation
- Refactoring legacy code while preserving behavior and reducing fear
- Establishing team discipline around tests-first workflows
- Triangulating behavior when generalizing implementations
- Introducing fast, unit-focused test suites to speed feedback
Best practices
- Write one failing test at a time and run it until it fails (RED)
- Make the smallest possible change to pass the test (GREEN), even if it’s ugly
- Refactor only when tests are green; remove duplication and improve names
- Keep unit tests fast and focused; prefer public-interface tests over private ones
- Use simplest test doubles (fake, stub, spy) and avoid mocking what you don’t own
Example use cases
- Build a small domain class with baby steps (e.g., Money/Dollar) using red-green-refactor cycles
- Drive algorithm generalization via triangulation: add examples until behavior is forced
- Introduce a test harness around legacy modules and refactor into smaller classes safely
- Write state-based assertions with fakes for repositories in service-layer tests
- Design APIs by writing client-facing tests first to drive public interfaces
FAQ
Prefer small, focused tests that express one behavior; one logical assertion per test encourages clarity and easier refactoring.
When is it okay to write a slower integration test?
Use integration and E2E tests sparingly for critical flows; the bulk of feedback should come from fast unit tests so development remains rapid.