Test driven development (TDD) is the practice of writing developer tests and implementation code concurrently and at a
very fine level of granularity.
In test driven design, the developer first writes a small test to validate a small change, runs the test to ensure that
it fails (a sanity check), and then writes just enough implementation code to make that developer test run
successfully. This cycle is short and it rarely goes beyond 10 minutes. In each cycle, the tests come first. Once a
test is done, the developer goes on to the next test until there are no more tests to be written for the implementation
of the work item currently under development.
The practice of test driven development changes how the developer thinks. Tests are not written as an afterthought.
Instead, developer tests are written as part of the everyday, every minute way of building software.
What are the advantages of test driven design?
-
Assumptions in the design are analyzed before the implementation code is written. To write developer tests, an
examination must be made of the behavior of each piece of code to be written. Correct and incorrect behaviors must
be defined. In a way, writing the tests before the code can be considered a version of detailed design.
-
Code units designed for testability up front are cleaner and more loosely coupled.
-
Errors are found earlier. Errors or gaps in the requirements and design are identified before coding begins, when
it could be tempting to move ahead based on assumptions.
-
A clearer collaboration strategy between the developer and others that might be responsible for the requirements,
architecture, and design is put in place. During the creation of the tests, there must be a meeting of the minds as
to what has been specified. After that, the implementation can carry on with confidence that there is a shared
vision of what the code should do.
-
There are unambiguous criteria for completion of the code. When the tests conclude successfully, the code is
working as specified. Non-functional quality dimensions can be dealt with separately, but there is a clear moment
when the code behaves correctly.
-
The technique drives the developer to work in smaller increments with faster quality feedback. At any time, the
developer is just one test away from having error-free code.
-
There is a separation of concerns and effort between getting code working and improving the quality of the code
that already runs correctly. Separating out these two areas of concern provides focus and time management support
to a developer. In one pass over the implementation, the developer makes it pass the tests as simply as possible,
and then in a subsequent pass, looks for areas to improve.
See Using TDD in context for more information.
|