experience report with TDD
I've seriously tried TDD in a real project, writing tests before code and following the red-green-refactor cycle. Short summary:
* I believe in TDD now;
* training and practice are required to learn TDD, reading books is not enough;
* the initial time investment is big.
The promise of TDD is that the profit appears in the long run, thanks to the better code design and possibility to change the code without breaking the existing functionality. Only future can show if it is really so.
Some statistics.
The task has taken 4 times more than I'd expect without TDD (40 hours vs 10 hours). However,
* 10 hours is an optimistic evaluation;
* I had to learn TDD and tools;
* I worked on a GUI component, which greately increases the complexity.
* I had to write the initial mock and fake objects for the parts of the applications, which are used by the component.
After the learning and preparation phases are done, I'd estimate the overhead coefficient to be less than 1.5.
My learning time:
* ~8h to actively read the book "Moder C++ Programming with Test-Drive Development" by Jeff Langr
* ~8h to re-learn on the real Python project.
The number of code lines:
* 350 lines: new functionality
* 600 lines: tests
* 240 lines: common test doubles
* ??? lines: refactored
Good things
"Avoiding 'legacy code' from the beginning". At some moment, I noticed that the code design was not so good as it could be. It was easy to refactor and immediately test the code without making a lot of clicks in GUI. Otherwise I'd have to retain the bad decision in just written code.
"Test names can serve as documentation": yes.
"Better design", "Code reuse". To test some functionality, I had to refactor existing code, extracting the fragments to a smaller functions. This way I noticed unexpected possibilities for new useful classes, which are useful also in other code.
"Next test helps start writing". Sometimes I just can't start coding. Fire and Motion by Joel Spolsky. With tests, there is always some easy task, which is easy to implement. Then the second. And then the programming "in flow" starts.