TDD Infected
In the past, I did not get what is the big deal about the whole TDD (Test Driven Development) thing. When I previously skimmed Kent Beck's "Test Driven Development book, I found the example in the book to be ridiculously simple or even dumb sometimes.
That is until I had chance to pair with Edward and watch the TDD in action.
We had a bug to fix and Edward had a hunch about where the bug is. But instead of going straight to fix it, he insisted on writing a test to reproduce the bug first. Unexpectedly, the first version of bug reproducing test didn't turn red. This lead us to fire up debugger and started tracing the code. Along the way, we discovered that our hunch was in fact wrong. When the test finally turn red, we knew exactly how to fix the bug. And sure enough, it took us no time to make the test green and we were confident that we indeed fixed the bug.
It is truly an "Aha!" moment for me.
So I revisited Kent Beck's TDD book afterwards. The book's example still read as ridiculous. But as I can relate to my personal TDD experience, the messages in the book begin to resonate with me.
Since I started to practice TDD couple weeks ago, the most important change is that I no longer try to "over-apply" patterns up front. I am able to delay that decision till the needs arise knowing comfortably that I can always refactor to pattern without fear of breaking anything. A big plus in my book.
Technorati Tags: programming
Comments
the tests are smaller, much more finely grained and not as fragile.
another excellent resource is the Manning book on Test Driven Development by Koskela
http://www.manning.com/koskela/
I've also written my own article
http://homepage.mac.com/hey.you
What I like about Koskela's book is that he really emphasizes the importance of aggressive refactoring. I've not done that very well and have a code based that is harder to change than I would like. thankfully with a good set of unit tests supporting the code, I can make big changes fearlessly.