Is there a difference between TDD and Test First Development (or Test First Programming)?

Question

Both ideas sound very similar to me, but there might be subtle differences or the exact same thing, explained in different ways. What is the relationship between TDD and Test Fi

Answer 1

Historically Correct: Test-First Programming and Test-Driven Development mean Same Thing with an Improved Name

In the context of XP (Extreme Programming), which is the software development process that made Test-First Programming and Test-Driven Development popular, Test-First Programming was renamed to Test-Driven Development and then Test-Driven Design following the realization that writing tests first has a tremendously positive effect on the software architecture and design of a software system.

This influence on architecture and design is a consequence of more or less surprising synonyms:

• Testable
• Decoupled
• Reusable
• Independently Deployable
• Independently Developable
• Independently Reasonable

Software entities can only be easily reused, tested, deployed independently, developed independently, or easily reasoned separately if they are decoupled. Writing tests before the actual implementation is an almost bullet-proof method to ensure continuous decoupling.

This influence on software design and architecture became so important besides the other positive effects that the creators found it worthwhile renaming it from Test-First Programming to Test-Driven Development.

The name Test-Driven Development also helps marketing the method better in terms of acceptance as well as proper understanding because the name Test-Driven Development emphasises better on the holistic aspects of the method than Test-First Programming.

Not Historically Correct but Useful

While historically not correct, I find the following distinction very useful:

Test-First Programming…

…is any method in which tests for the code under test are written before the code under test.

Test-Driven Development…

…is a specific subset of Test-First Programming that follows the 3 Laws of Test-Driven Development as described by Robert C. Martin:

1. You can't write any production code until you have first written a failing unit test.
2. You can't write more of a unit test than is sufficient to fail, and not compiling is failing.
3. You can't write more production code than is sufficient to pass the currently failing unit test. — Robert C. Martin, The Three Laws of Test-Driven Development

Following these three rules puts you in what is called the Red-Green-Refactor cycle. 1. You write a failing test. 2. You make it pass. 3. Now that it passes, you can refactor mercilessly before writing the next failing test.

Note that refactoring safely requires tests. Refactoring means changing the structure of source code without changing the significant behavior. But how do we know that we haven't accidentally altered significant behavior? What defines significant behavior? That's one of the many things for which tests are useful.

BTW if your tests get in the way of refactoring, your tests are too low-level, too tightly coupled, and maybe you've used too much mocking.

Other interesting renames in Extreme Programming

• Continuous Integration -> Continuous Delivery -> Continuous Deployment; Strictly speaking they mean different things, however, in the spirit of XP, it meant Continuous Deployment from the start, and when people jumped on the bandwagon, it was realized that integration was taken too literally and people stopped before they are done.
• Continuous Refactoring -> Continuous Design Improvement; Refactoring is not a means to an end in itself, but follows a higher purpose.
• 40 hours week -> Sustainable Pace (Urban legend: This rename happened after protests by French software developers.)