tdd-workflow

TDD Workflow

When to Use

• Building new features where correctness is critical
• Fixing bugs where a regression test should be written first
• Refactoring code that lacks test coverage
• Working on business logic, parsers, or data transformations

Prerequisites

• Test framework installed and configured (Jest, pytest, Go test, etc.)
• Ability to run tests from the command line
• Understanding of the feature requirements or bug to reproduce

Language	Common frameworks	Example commands
JavaScript / TypeScript	Jest, Vitest	npm test, npx vitest
Python	pytest	pytest
Go	go test	go test ./...
Ruby	RSpec, Minitest	bundle exec rspec, ruby -Itest test/
PHP	PHPUnit	./vendor/bin/phpunit
Rust	cargo test	cargo test

tdd-guard users: v1.7.0 improves SDK validation error handling, reduces response tokens for allow-operation, and refactors hook-payload parsing. After bundle add tdd-guard, re-check its framework detection before relying on automatic enforcement.

Workflow

0. Choose the Thinnest Slice First

Before you write or change anything, shrink the task to the smallest meaningful behavior that can go through one Red → Green → Refactor loop.

Good first slices usually have all three properties:

• one visible behavior change
• one main assertion path
• one reason it could fail

If the first test needs multiple branches, multiple modules, or a large fixture to make sense, shrink it again. After each Green phase, pause long enough to confirm the direction before stacking more behavior on top.

1. Pre-Check — Does a Test Already Exist?

Before writing a new test, verify you are not duplicating existing coverage.

glob pattern="**/*.{test,spec}.{js,jsx,ts,tsx}"
glob pattern="**/{test_*,*_test}.py"
glob pattern="**/*_test.go"
rg pattern="<function-or-behavior-name>" path="."

If an equivalent test already exists, extend or correct it instead of creating a duplicate. If not, proceed to write the failing test.