What is Test Driven Development? Does it require to have initial designs?

Question

I am very new to TDD, not yet started using it. But I know that we have to write test first and then actual code to pass the test and refactor it till good design.

My concern over TDD is that where it fits in our SDLC. Suppose I get a requirement of making order processing system. Now, without having any model and design of this system, how can I start writing tests? Shouldn't we require to define the entities and its attributes to proceed? If not, is it possible to develop big system without any design?

Answer 1

There is two levels of TDD, ATDD or acceptance test driven development, and normal TDD which is driven by unit tests.

I guess the relationship between TDD and design is influenced by the somewhat "agile" concept that source code IS the design of a software product. A lot of people reinforce this by translating TDD as Test Driven Design rather than development. This makes a lot of sense as TDD should be seen as having a lot more to do with driving the design than testing. Having acceptance and unit tests at the end of it is a nice side effect.

I cannot really say too much about where it fits into your SDLC without knowing more about it, but one nice workflow is:

For every user story:

1. Write acceptance tests using a tool like FitNesse or Cucumber, this would specify what the desired outputs are for the given inputs, from a perspective that the user understands. This level automates the specifications, or can even replace specification documentation in ideal situations.

2. Now you will probably have a vague idea of the sort of software design you might need as far as classes / behaviour etc goes.

3. For each behaviour:

4. Write a failing test that shows how calling code you would like to use the class.

5. Implement the behaviour that makes the test pass

6. Refactor both the test and actual code to reflect good design.

7. Go onto the next behaviour.

8. Go onto the next user story.

Of course the whole time you will be thinking of the evolving high level design of the system. Ideally TDD will lead to a flexible design at the lower levels that permits the appropriate high design to evolve as you go rather than trying to guess it at the beginning.

Answer 2

It should be called Test Driven Design, because that is what it is.

There is no practical reason to separate design into a specific phase of the project. Design happens all the time. From the initial discussion with the stakeholder, through user story creation, estimation and then of course during your TDD sessions.

If you want to formalize the design using UML or whatever, that is fine, just keep in mind that the code is the design and everything else is just an approximation. And remember that YAGNI applies to everything, including design documents.