12 Comments Starting with Test-driven development - 02/26/09
I received some great how-to-start-with-TDD-advice from Davy a few months ago. I’m still a TDD-newbie, that’s for sure, but I sure have learned a lot during these past months. Since I think Davy’s advice gave me a great head start, I thought I’d share it with all the developers that want to start with TDD. Thanks to Davy!
Start small, VERY small
My problem when I began, was that I started waaaay too big. I was worrying about how to test complex scenario’s, even before I wrote the very simple tests, test-first.
When you’re just starting, try not to think about these problems just yet. Start out very simple, with code that’s easy to test and doesn’t even require more advanced techniques such as test doubles. Once you get to the more complex ones, you’ll already be a step further.
One rule I always keep in mind: if the code I want to write is so complex that I don’t even know how to test it, it’s time to split it up in smaller tests.
Read about it
You’ll find lots and lots of information on blogs out there, but I think you should start with Kent Beck’s Test-driven development by example (I’ll talk about this book later). I’m not saying the info on blogs isn’t valuable, I’m just saying there are better resources out there to learn the basics. Reading blogs about TDD without knowing the basics well, caused me a lot of confusion because of several reasons:
First, because TDD-posts mostly assume some level of TDD-knowledge, and usually more than knowing the red-green-refactor cycle. Second, because at the end of the road, posts are personal opinions and personal perceptions, which aren’t always completely correct, so you’ll find contradictory opinions and won’t know which one is correct. Once you understand the TDD-basics, you’ll get much more value out of all the information TDD’ers are sharing with us on the net.
TDD by example is a great book to get started. It’s about 200 pages long and it’s extremely easy to read. Once you’ve read it, you’ll be able to start practicing it, talking about it and understanding it’s value. What I also enjoyed a lot, is that Kent writes the book just like you’re thinking now (a not TDD-mentality) => “Let’s implement this. We should call this method, and then perform a calculation… Shame on me! I should start test-first!”. I loved it!
After this one, you can read xUnit Test patterns, which is a more advanced book that describes the patterns you’ll commonly use during testing. I’ve just started to read it (finally) and I’m already enjoying it. This is not going to be a quick read (900 pages), but I know it’ll be very valuable.
Apart from the books, I’d also recommend to read Martin Fowler’s paper about the difference between mocks and stubs, which you can find here. It’s a quick read and it’s very clarifying.
Don’t give up
It won’t be easy, it’s a complete mind-shift. I’ve been in the situation a lot of times that I began test-first, and ended up writing everything test-after. The clue is not giving up, or as Davy might say, be stubborn! The advantage I’ve had is, that I felt guilty whenever I was testing-after, so whenever I got to new functionality, I began test-first again.
Even now, when I’ve just implemented something I’ve tested and I’m green again, I find myself starting to type some new method somewhere. At that point, I try to be very strict with myself, delete what I just typed, and get back to my test suite and write a new test. Remember red-green-refactor !
Apart from discipline, I think the easiest way to hold on when learning TDD, is having an experienced TDD’er in your direct environment. But that’s just not always possible. When I got into TDD, I was working with people that don’t saw any value in testing at all (not even in tests-after-coding), so that shouldn’t stop you!
A final word
In my limited and humble experience, I can say that I’ve only experienced advantages from the TDD-approach. It may be the hard way in the beginning, when you’re learning it (and I still havn’t completely passed that stage), but the value you get out of it (less bugs, reliability, clear design, more focused and clean code) isn’t representative to the time you invest in it.