Lately, I’ve gotten into the habit of keeping a ton of can’t-forget-to-read-this articles open in separate tabs in my browser. It’s gotten to the point where I have so many tabs open that I can’t remember why or how I got to the tab in the first place. It’s kinda fun, though. Going back through the tabs feels like browsing new content that’s all be hand-picked by me for me. Thanks, me of the past!
I was flipping through some of the older tabs and found this Microsoft Patterns & Practices article about unit testing. This article is a bit long, but it serves as a good introduction to unit testing, touching on a variety of topics related to unit tests and automated system testing. There were a couple of cartoons about test-first development that I really liked in this article.
Writing unit tests before you write the code—test-first development—is recommended by most developers who have seriously tried it. Writing the tests for a method or interface makes you think through exactly what you want it to do. It also helps you discuss with your colleagues what is required of this particular unit. Think of it as discussing samples of how your code will be used.
For example, Mort, a developer at Fabrikam, has taken on the task of writing a method deep in the implementation of an ice-cream vending website. This method is a utility, likely to be called from several other parts of the application. Julia and Lars will be writing some of those other components. They don’t care very much how Mort’s method works, so long as it produces the right results in a reasonable time.
In the comic, Mort has been given some requirements and is left to come up with implementation details on his own. He writes tests to show an example of how his method will be used as well as to build in some assumptions. The point of test-first development is that you come up with a way to test before you begin coding. In practice, this is easier said than done, but it’s a good habit to get into. Writing tests first ensures that you write good, testable code. When you write the solution first, it’s much easier to end up with poorly tested or untested (gasp!) code.
The second comic introduces a new piece of functionality. Note that no code had been written at this point, but a new test is added to verify a different behavior of the same code. At the end of the comic, Mort points out that all that’s left to do now that the tests are in place is to write some code that makes the tests pass. Time is spent writing tests and thinking through requirements and scenarios up-front. Then, when you move on to the “real” development, it’s much easier because you’re just writing code to make the tests pass. (Way better than running code and repeating manual tests over and over again!)