tdd

Guides Go test-driven development using the red-green-refactor loop with vertical slices.

1|2|Updated Nov 25, 2017
One-click install
npx skills add https://github.com/asarchami/dotfiles --skill tdd-asarchami
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/asarchami/dotfiles/tree/main/dot_config/opencode/skills/tdd
Command: npx skills add https://github.com/asarchami/dotfiles --skill tdd-asarchami

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after implementation or in bulk produces brittle tests coupled to internal structure that break during refactors. This Skill enforces a disciplined red-green-refactor workflow so Go tests verify behavior through public APIs and survive code changes. ## Core Features & Use Cases - Red-Green-Refactor Workflow: Structures development as vertical tracer-bullet slices, one test and one minimal implementation per cycle, avoiding horizontal slicing anti-patterns. - Go Testing Conventions: Provides guidance on table-driven tests, testify assert vs require, integration test build tags, and interface design for testability. - Mocking Boundaries: Defines when to mock (system boundaries only) with testify/mock and hand-written mock patterns. - Use Case: When implementing a new Go service like a ticker service, use this Skill to plan the exported API, write one failing behavior test, implement minimal code to pass, and repeat until all behaviors are covered. ## Quick Start Use the tdd skill to implement the new checkout feature in Go using test-driven development with one behavior test at a time.

Frequently Asked Questions about tdd

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I practice test-driven development in Go?

Follow the red-green-refactor loop: write one failing test for a single behavior, write minimal code to pass it, then repeat for each remaining behavior. Refactor only after all tests pass, never while red.

Should I write all tests before implementation in TDD?

No. Writing all tests first is horizontal slicing and produces brittle tests of imagined behavior. Use vertical slices instead: one test, one implementation, repeated, so each test responds to what you learned from the previous cycle.

When should I use testify/mock versus hand-written mocks in Go?

Use testify/mock for interfaces with four or more methods or when you need AssertExpectations and flexible argument matching. Use hand-written mocks for tiny interfaces of one to three methods or when each test needs unique closure-based behavior.

What is the difference between testify assert and require?

Use require when a failure should abort the test immediately, such as setup errors or nil results. Use assert when the test can continue checking other conditions after a failure.

When should I not mock dependencies in Go tests?

Only mock at system boundaries like external APIs, databases, time, and file systems. Do not mock your own packages or internal collaborators, since that couples tests to implementation and breaks them during refactors.