First, TDD is not about having unit tests. TDD is a about software design and about specifying software requirements. Using TDD will improve your coding and the product.
TDD and Legacy Code
TDD and legacy Code is a combination from hell. Use TDD for new code parts. TDD will punctual improve the software quality. Don’t try to TTD-ing the complete legacy code, this is an idea from hell, you will get mad. Containment is the better option for legacy code. Build some tests around your legacy code, that covers and describes the most important code flows.
OK some words why I’m a big TDD fan.
- TDD saves time by reducing the time finding bugs in your implementation and believe me your code and my code containing bugs at least in the early iterations. A debugger is common tool for most developers, I don’t need it. I take the debugger only if I handle legacy code. TDD is an inverse debugger.
- It makes refactoring save and enables iterative software development
- It’s a driver for decomposition and the separation of concerns
- You don’t have to write extra tests, only few integration tests
I never seen TDD in real life. That means most developers are not using TDD.
There is on major disadvantage of TDD, it is not common. Every developer heard about TDD but that’s all.
What are barriers of using TDD, as far as I know
- Never tried it
- Stereotypes like: time expensive
- Routine
- No need
How to break down the barriers
- Try it.
- Pair programming
TDD and Test Coverage
Drop Test Coverage Metrics, they are useless. Test Coverage Metrics are to avoid, they costs productivity.
A major misunderstanding is the believe that a high test coverage is a software quality criteria. That is false. But what is true a TDD project have a high quality and have a high test coverage. Don’t mix-up causality and correlation.
Last Words
TDD is a blend of test first, decomposition pattern and iterative software development. Try it.
No comments:
Post a Comment