Test Driven Development (TDD) in a Nutshell
The Agile concept of Test Driven Development (TDD) has stood the test of time, emerging from the shadows cast by the test-first programming concepts of XP from where it originated (with the release of Kent Beck’s Test Driven Development by Example in 2002). Much of its success can be attributed to its simplicity in concept, differentiating it from other popular development models. TDD relies on an understanding of both incremental design, – where unnecessary complexity is never added, and emergent design where design emerges over time. In regards to the effectiveness of TDD, it is a large part down to how good the practicioner is at emergent design. It has become widely used for extending and debugging legacy systems.
As the name implies, the test sets the agenda in TDD, an automated test case is created that defines the desired functionality and is subsequently tested. TDD is based upon unit testing, and therefore the developer writing the code tends to write the unit test, and consequently tends to write code in small chunks. Typically, Test Driven Development is characterised by short development cycles of between 8-10 code edits. Each development cycle is comprised of 5 steps that are repeated until the the code meets the quality standard required.
Pros and Cons of Test Driven Development (TDD)
The short well tested development cycles of TDD provide several key benefits including:
- Test Availability – During the addition of new features or refactors of code bugs can be detected thanks to regression testing.
- By writing unit tests the programmer is challenged to consider edge cases and implications.
- Minimizes the debugging effort (smaller development cycles = easier to track)
- Development team stays focused on what the customer wants (enhanced by ATDD)
- The smaller test cases are easier to understand (self documenting test cases).
- Less need to invoke debugger when used in conjunction with a version control system, – often far more productive to revert to the last version that worked.
- Forces the programmer to imagine how the functionality is used by the users.
- Since programmers writing the code test the code there are often missed opportunities for testing, – blind spots
- If the developer misinterprets the feature requirements then tests created for testing the code for the feature will be wrong also.
- Tests are often not checked by 3rd party so therefore are more likely to contain errors.
- A Unit test can be more complicated than the code its testing, and is therefore an overhead
- A high unit testing success rate can provide a false sense of security resulting in other tests being skipped (integration testing, compliance testing)
Although TDD has been around for more than a decade, it remains entirely relevant today, ideal for the extension of Agile to DevOps since continuous testing and continual improvement, are a requirement for both TDD and DevOps (for more on DevOps).
codeBeamer ALM includes QA + Test Management which provides a clear and transparent mechanism for collaborating on unit testing (and automating testing) for TDD, negating many of the negative aspects (weaknesses) of unit testing. Unmatched clarity and capture of the transformation process of user demand (demand management) into application requirements (requirements management) make codeBeamer ALM the ultimate choice for unit testing for application development.
Furthermore, codeBeamer ALM provides complete transparency and traceability for all concerned, with access control completely configurable for all your project requirements.