beck-tdd_skill

This skill helps you adopt Kent Beck's test-driven development discipline, guiding red-green-refactor, small steps, and emergent design for reliable Python
  • 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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational