Search code examples
unit-testingtddsoftware-design

What is test-driven development (TDD)? Is an initial design required?

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

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

Solution

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