Originating from the release of Kent Beck’s Test Driven Development by Example in 2002, the Agile concept of Test Driven Development (TDD) has stood the test of time. Much of its success can be attributed to its simplicity, 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. It is also used to improve and debug legacy code that was written with other techniques.As the name implies, testing sets the agenda in TDD. First, test cases accurately defining the desired functionality are created. These will then guide development so that features are delivered to pass those tests only. TDD is based upon unit testing, and code is written in small chunks. Typically, Test Driven Development is characterised by short development cycles of between 8-10 code edits. Each development cycle is composed of 5 steps that are repeated until the the code meets the quality standard required.
Pros and Cons of Test Driven Development (TDD)
As is the case with so many Agile software development methods, TDD has as much critics as proponents. Fair enough, just like any other method, it has its advantages and disadvantages, knowledge of which helps you decide whether TDD is for you.
- Test Availability – Regression testing helps detect bugy during the addition of new features or the refactoring of code
- By writing unit tests, the programmer is challenged to consider edge cases and implications
- With its incremental and test-driven nature, TDD also promotes modular design
- Minimizes the debugging effort (earlier identification of problem, easier code refactoring, smoother collaboration)
- Helps maintain focus on user needs
- Smaller test cases are easier to understand (self-documenting test cases, deeper understanding of code)
- Reduced effort of debugging when used with a version control system (it is often far more productive to simply revert to the last version that worked)
- Since programmers are writing both test cases and the code, there might be blind spots (missed opportunities for testing)
- Misinterpreted requirements will lead to test cases that will pass, but won't help to build a quality feature that fits customer needs
- Tests are often not checked by any 3rd party stakeholders and so are more likely to contain errors
- Implemeting TDD can be a slow process at first that only pays off in the long run (plus it's difficult to make the switch if you've spent years working with another method)
- A high unit testing success rate can provide a false sense of security resulting in other tests being skipped (integration testing, compliance testing)
- Creating test for failures is necessary but tedious work
TDD has been around for more than a decade, and while it has gained a bit of traction, it's not as much of a hot topic as other methods. But it still is entirely relevant, and in fact ideal for the extension of Agile to DevOps because of its emphasis on continuous testing and continuous improvement.
codeBeamer ALM's functionality spanning the entire lifecycle makes it easy to implement Test Driven Development. It provides a transparent and efficient platform of collaboration and QA. With advanced test management features, automated documentation, and quality monitoring, it greatly facilitates the use of TDD. For more information, contact us with your questions, or start your free trial right away!