// PROACTIVELY enforce Test-Driven Development when implementing features or fixing bugs. Ensures tests are written BEFORE code. Use for new methods, services, repositories, or bug fixes. Guides RED-GREEN-REFACTOR cycle.
PROACTIVELY analyze completed Beads issues to identify patterns, tech debt, and gaps. Suggests new OpenSpec proposals based on discovered work. Use after closing issues or when user asks "what should we work on next?"
PROACTIVELY convert approved OpenSpec specs into Beads issues when user applies a change or explicitly approves implementation. Creates trackable work with dependencies, discovers gaps, and maintains audit trail between planning and execution.
| name | tdd |
| description | PROACTIVELY enforce Test-Driven Development when implementing features or fixing bugs. Ensures tests are written BEFORE code. Use for new methods, services, repositories, or bug fixes. Guides RED-GREEN-REFACTOR cycle. |
Guide Claude to follow strict Test-Driven Development practices when implementing new features or fixing bugs. Ensures tests are written BEFORE implementation code.
RED → GREEN → REFACTOR
↓ ↓ ↓
Fail Pass Improve
Before writing any test, Claude MUST:
See examples/dialogue-examples.md for examples of clear vs ambiguous entity identification.
Place test files next to the code being tested:
internal/service/
├── transaction_service.go
└── transaction_service_test.go ← Test file here
pkg/ofx/
├── parser.go
└── parser_test.go ← Test file here
Pattern: Test<EntityName>_<MethodName>_<Scenario>
See data/naming-conventions.md for detailed naming guidelines and examples.
// ✅ GOOD - Clear entity, method, and scenario
func TestTransactionService_ImportFromOFX_WithDuplicateFITID(t *testing.T)
func TestOFXParser_Parse_WithInvalidXML(t *testing.T)
func TestBudgetRepository_Create_WithNullAmount(t *testing.T)
// ❌ BAD - Missing entity or scenario
func TestImport(t *testing.T)
func TestValidData(t *testing.T)
Focus on:
Don't test:
See data/coverage-guidelines.md for what to test and what to skip.
Use templates from templates/test-structure.md:
func TestTransactionService_ImportFromOFX_Success(t *testing.T) {
// ARRANGE - Setup test data and dependencies
mockRepo := &mockTransactionRepository{}
parser := ofx.NewParser()
service := NewTransactionService(mockRepo, parser)
ofxData := []byte(`<OFX>...</OFX>`)
accountID := uuid.New()
// ACT - Execute the method being tested
result, err := service.ImportFromOFX(context.Background(), ofxData, accountID)
// ASSERT - Verify expectations
require.NoError(t, err)
assert.Equal(t, 5, result.Inserted)
assert.Equal(t, 0, result.Skipped)
}
See examples/feature-implementation.md for complete examples:
BudgetService.CalculateEffectiveAmount()Test 4 main cases for each method:
From data/coverage-guidelines.md:
See templates/test-structure.md for mock templates:
// Define interface in domain
type TransactionRepository interface {
BulkInsert(ctx context.Context, txs []*Transaction) error
}
// Create mock in test file
type mockTransactionRepository struct {
mock.Mock
}
func (m *mockTransactionRepository) BulkInsert(ctx context.Context, txs []*Transaction) error {
args := m.Called(ctx, txs)
return args.Error(0)
}
Before writing implementation code, Claude MUST:
*_test.go)After test fails, Claude can:
WRONG: "I'll implement ImportFromOFX, then test it"
RIGHT: "I'll write a test for ImportFromOFX first, then implement"
One scenario per test function.
Always specify which entity (Service, Repository, Handler) is being tested.
Test public behavior, not internal variables or private methods.
See examples/dialogue-examples.md for:
TDD in 3 Steps:
Always remember:
Golden Rule: If you're writing implementation code without a failing test, STOP and write the test first.
examples/feature-implementation.md and examples/dialogue-examples.mdtemplates/test-structure.md for test patterns and mocksdata/naming-conventions.md for naming guidelinesdata/coverage-guidelines.md for what to test