What TDD is not about
TDD is not so much about what tool you are using. TDD is tool-agnostic. The best way to do TDD is to use the same programming language. If you're looking for tools, you look in the wrong direction.
It's not about having a high test coverage. It's not about minimizing quality risks. In fact, it's not a Quality Assurance technique at all. If you use TDD for finding bugs, you're definitely on the wrong track.
What TDD is about
The key to successful TDD is to produce code in a fashion that each component is fully inspectable down to the most granular level, so that:* You have a good software design
* You fully understand what each component, method and API does
* You minimize overhead of future reverse-engineering
* You lay a basis for easy changes, so that now you don't need to waste time on thinking about possible future changes
* If you need to change something fundamentally, you know where to best do it
* If something doesn't work as intended, you can isolate the root cause quickly
Summary
The main reason to employ TDD is not if you have "lots of defects". Chances are that you will not only not reduce the defect count with TDD on a poor quality legacy application - but that you will invest a lot of effort into increasing coverage without getting any measurable benefit to the user (customer) at all.
The best reasons to employ TDD are: when developers complain that they can not make changes to the software easily or they complain that finding the root cause of defects takes forever.
TDD is architecture+design topic.
The first minute you start doing TDD, each new line of code written, you will be working towards a better software design. It definitely pays off in the long term.
Just don't look at the release defect metric, because you will not see the benefit there.
No comments:
Post a Comment