Writing unit tests first can be a big win on several counts.
By writing the tests first, you confront your new code with a real client of its API. This cuts way down on imaginitive design-ahead that later (when you finally try to use it) proves problematic.
I used to try to think three or four steps ahead when designing and implementing class hierarchies, before actually using the code. It's a fun head game, but more often than not I ended up with unused, untested artifacts that bit back months later.
Now I limit implementation to one "story" at a time, and (largely) avoid having unused, untested code.
By having a body of unit tests to cover the work already implemented, the feedback loop for discovering that I've broken something "way over there" is very short. The code I've just implemented is still fresh in my head, and I can think through consequences without having to take hours to rebuild mental context.
By keeping the bug count down (ideally to zero) at each step of development, there's no chance for the bugs to breed while nobody is looking. The number of "cascading" bugs I find in my own code has gone down to effectively zero.
The other Extreme Programming practice I used with this is Refactoring. After each development iteration, I look at the code, and refactor where necessary (refactor classes, break long routines into smaller pieces where appropriate, etc.). (And rerun the unit tests!) Think of it as cleaning the kitchen after cooking. It's such a bummer to walk into the kitchen to start cooking, only to find dirty pots and pans that need to be cleaned first. I find that it's the same way with code.
Shifting my development habits to writing test cases first wasn't easy. The temptation to jump right in and start coding the "real" stuff was strong. If you go this route, expect there to be starting friction, and hang with it a while until you notice your debugging time dropping off.
| [reply] |
after reading your question and following the discussion I too tried this out and found the same things. Only difference is I actually took an older project, applied the method to it and shook out some bugs I couldn't believe had not been caught. They were the kinds of things that people may have run accross and worked around (one definitely was according to one of the users who said they'd seen it), but it was absolutely frightening to think about how many bugs there actually were creeping around in something long considered "production".
"A man's maturity -- consists in having found again the
seriousness one had as a child, at play." --Nietzsche
| [reply]
[d/l] |
It's been a great big win on Jellybean, so far.
Test-first is probably the largest benefit, though breaking up my plans into stories, then into tasks, and then implementing each task as simply as possible helps too.
The design is better, I have more confidence in the code, and I spend less time stopping and restarting the server to test a new feature. It's also a lot easier to improve the code without worrying about breaking other things.
Just this afternoon, OeufMayo and I tracked down and fixed a couple of bugs because we can both run the unit tests... and we're in completely different time zones. (He's a francophone, and I have my own little piece of paradise in western North America.)
The instant feedback is also nice.
It's not working so well on translating Rogue from C to Perl, but that's probably because I'm stuck on the dungeon-generating algorithms. They're rather hard to test. | [reply] |