| Understand what TDD is and why it matters |
TDD Overview |
You're starting a new feature, fixing a bug, or working on complex business logic where you want to catch errors early and design better code through tests. |
| Know when to use TDD vs traditional testing |
TDD vs Traditional Testing |
You're deciding whether to adopt TDD for a project or choosing testing strategy for different parts of your codebase. |
| Learn the core rules of TDD |
The Three Laws of TDD |
Every TDD cycle runs on these three laws; Law 2 - stop the test the moment it fails, not when it feels complete - is the one most often skipped. |
| Follow the TDD workflow step-by-step |
Red-Green-Refactor Workflow |
Every time you implement a new feature or fix a bug using TDD. This is the core TDD workflow. |
| Know whether I'm allowed to change an existing test |
Changing Existing Tests |
Before changing an assertion or deleting a test, check the mutability matrix for who may touch it; an adversarial reviewer never edits or deletes a test it's judging - it files a finding instead. |
| Fix a bug without growing the suite |
Fixing Bugs with TDD |
Fixing a bug: write one failing test that reproduces it, fix only until that test passes, then stop - don't add tests for untouched behavior or strengthen neighboring assertions in the same change. |
| Know whether a test belongs to TDD or to another discipline |
What TDD Covers |
A test belongs to the TDD loop only if it can be written before the code and watched to fail; E2E, visual regression, performance, and security scans are outer verification, not TDD coverage - driving a browser is not the discriminator. |
| Decide whether an added test should exist at all |
When Not to Write a Test |
TDD requires one specification per behavior a change creates, seen failing before the code existed; anything else is excess unless it's a different discipline's test, but excess is never an excuse to skip the one required test. |
| Know whether the RED I saw proves the test came first |
What a Failing Test Proves |
A red run proves the order the commands ran in, not that the test came first: absence-RED constrains the design, mutation-RED only proves the test can fail, and a test green on arrival ratifies code that already works. |
| Write effective unit tests |
Unit Testing Fundamentals |
Writing any unit test: follow FIRST, and assert only on a promised contract - a return value, a state change, a documented error - never on a log line or call order nobody promised to keep stable. |
| Use mocks, stubs, fakes, and spies correctly |
Test Doubles |
You need to test code that depends on external systems (databases, APIs, file systems) or collaborating objects that are slow, unavailable, or difficult to set up in tests. |
| Structure my tests properly |
Testing Patterns |
Structuring any test - unit, integration, or end-to-end. These patterns create readable, maintainable tests. |
| Understand spec-driven development |
Spec-Driven Development Overview |
You're using AI coding assistants and want to maintain control over architecture while leveraging AI for implementation. Essential for production-quality code generation with tools like Claude Code, GitHub Copilot, Cursor, or Amazon Kiro. |
| Write specifications that drive implementation |
Writing Effective Specifications |
Before implementing any feature using AI code generation or when you want specifications to serve as living documentation and development contract. |
| Use AI to generate code from specs |
From Spec to Implementation |
You have a detailed specification and are ready to generate or write code using AI assistance, or you're manually implementing code that must match a specification. |
| Plan integration testing strategy |
Integration Testing Strategy |
Your unit tests verify individual components work correctly, and now you need to verify they work together correctly. Essential for multi-component systems, APIs, databases, and microservices. |
| Set meaningful coverage goals |
Test Coverage Strategy |
You're deciding what to test, how much to test, and evaluating whether your test suite is adequate. Coverage metrics are tools for finding gaps, not goals to hit. |
| Refactor safely with test coverage |
Refactoring with Confidence |
Code works but is messy, duplicated, or hard to understand. You want to improve structure without breaking behavior. |
| Avoid common TDD mistakes |
TDD Anti-Patterns |
You're practicing TDD or reviewing tests and want to identify common mistakes that reduce test value or create maintenance burden. |
| Apply TDD security best practices |
Security Best Practices |
Writing tests for any code that handles authentication, authorization, user input, sensitive data, or external integrations. Security must be tested, not assumed. |
| Optimize test performance |
Performance Best Practices |
Writing performance-critical code, optimizing slow tests, or ensuring your test suite runs fast enough to be run frequently. |
| Follow development standards |
Development Standards |
Every development project using TDD or testing. These standards ensure code quality, maintainability, and team consistency. |
| Find testing resources by language |
Code Reference Map |
|