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

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 First Development/Programming?

There's a difference in terms of what the driving factor is.

Do you have a vague idea of what the class (or system - this can happen at different scales, of course) should look like, then think up tests which give it the actual shape? That's TDD.

Do you know exactly what the public API of the class should be, and just write the tests before the implementation? That's test-first development.

My style tends to be a mixture of the two. Sometimes it's obvious what the API should be before writing any tests - in other cases testability really drives the design.

To put it another way, TDD starts with "What questions do I want to ask?" whereas non-TDD (whether test first or not) starts with "What answer do I want to give?"

They are basically different names describing the same thing - well, in fact five names, as the last D can stand for Design as well as for Development.

Test First was the term used originally, especially in the context of Extreme Programming, for the test-code-refactor cycle. The name Test Driven Development has been proposed - and quickly adopted - later, to stress the fact that TFD is - and always has been - more of a design strategy than a testing strategy.

Obviously today some people have different connotations for those two terms, but that wasn't the intent behind their existance, and I wouldn't rely on it being common knowledge (because it's not). In fact, I'd rather see the term TFD as being deprecated.

The are a lot of similar terms like test-first programming, test-first development, test-driven development or even test-driven design. It is important to clarify a few points:

1. Test First Programming (TFP)

The term test-first programming is a programming best practice. It was reintroduced (if not coined) by Kent Beck in his book “Extreme Programming Explained”: “Write unit tests before programming and keep all of the tests running at all times”. So, when talking about test-first programming we are talking about writing automated unit tests by the very developer that is going to write the code to satisfy those tests. The unit tests pile up and build an automated regression test suite that could be run periodically.

2. Test Driven Development (TDD)

Test-driven development (TDD) is the name of a methodology introduced by Kent Beck in his book "Test Driven Development by Example". It is a software development process, it is not only about writing tests before code. The whole book is trying to explain it by patterns, workflows, culture and so forth. One important aspect of it is the emphasis on refactoring.

Some people use the terms test-first development, test-driven design, or test-driven programming and ... One thing is for sure: the well established methodology is test-driven development and the programming technique is test-first programming. The rest are either generally referring to the idea of writing tests before code or mistakenly referring to test-driven development or test-first programming.

TDD = TFD + Refactoring.

When you do TFD , you apply some refactoring to make code more generic and robust.

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. > 1. You can't write more of a unit test than is sufficient to fail, and not compiling is failing. > 1. 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][1]

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.

[1]: http://programmer.97things.oreilly.com/wiki/index.php/The_Three_Laws_of_Test-Driven_Development "The Three Laws of Test-Driven Development"

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.)

In Test Driven Development: By Example, the author, Kent Beck, clearly states that "test first" (TF) is the rule. So TF is the principle that rules TDD. The later one is the process.

TDD (Test Driven Development) is Test First Development/Programming although I have seen and heard TDD used to mean creating persistent, repeatable unit tests (even after the code), but really it implies the tests are written before the code they are testing.

They are exactly the same thing. Both reference writing tests first, then writing the code that will pass the test