test-driven-development

Test-Driven Development (TDD)

Skill Overview

A development methodology in which tests are written before implementing the actual code. The “Red-Green-Refactor” cycle ensures code quality and prevents regressions.

Suitable Scenarios

New Feature Development

When implementing any new feature, first write a failing test to define the expected behavior, then write the minimum code required to make the test pass. This ensures the code has test coverage from the start and that the interface design matches real usage needs.

Bug Fixes

When fixing a bug, first write a failing test that reproduces the issue, ensuring that once it’s fixed, the problem won’t happen again. Tests act as regression protection, preventing the same bug from being reintroduced in the future.

Code Refactoring

With test coverage as protection, clean up and optimize the code. The test suite serves as a safety net, allowing you to improve the code structure confidently without worrying about breaking existing behavior.

Core Capabilities

Red-Green-Refactor Loop

The core three-step process of TDD: write a failing test first (red), implement the minimum code to make it pass (green), then clean up and improve the code (refactor). Each cycle keeps the tests passing, ensuring the code is always in a working state.

Verification-Driven Development

Forces developers to see failing tests, confirming that the tests truly verify the intended behavior rather than testing the wrong implementation. This helps avoid the common pitfall of “the tests pass, but the functionality is wrong.”

Defensive Programming Guidance

Provides boundary guidance for using TDD (when to use it and when exceptions apply), and helps identify common rationalizations and warning signs that prevent the team from slipping into the anti-pattern of “writing code first, adding tests later.”

Common Questions

What are the core principles of TDD?

The core principle is: “Don’t write production code unless there is a failing test.” This ensures each line of code is written to satisfy a specific, clear need, and that there is automated test protection. If you don’t see tests failing, you can’t confirm that it truly tests the right thing.

Does TDD slow down development?

It may feel slower in the short term, but faster in the long run. TDD reduces debugging time (bugs are caught when they’re introduced), eliminates the manual effort of regression testing, and makes refactoring safe. Instead of spending hours debugging production issues, spend a few minutes writing tests.

When should you not use TDD?

TDD applies to all feature code and bug fixes. Exceptions should be discussed with the team: one-off prototypes, automatically generated code, and configuration files. But note that the idea of “skipping this time” is often a rationalization—once you start making exceptions, it’s easy to turn it into a habit.