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