For the past three years I’ve been trying to emphasize and build unit tests at Mint.com. I’ve tried TDD and some other approaches but nothing has kept up pace with an agile-like speed of development. The article Is Unit Testing Doomed? talks about the issues that developers have today with all the different philosophies of unit testing, and why so many opt out of doing it. Instead of forsaking unit testing because I couldn’t find the right methodology to suite my needs, I decided to come up with my own home grown version of it.
My approach is to design the entire project’s front and back-end’s set of interactions, then the data model to represent the back-end. I then break the design apart into components that I plan on implementing. After implementing each piece I write some unit tests for the apis I have developed. I do this for each component or logical unit I am developing. I use stubs to avoid class dependencies and focus on the class I am testing.
Since I’m operating in an agile-like environment the design is sure to change, in the event that it does I haven’t wasted a whole lot of time by writing test cases up front using TDD. I can go in and quickly modify a few test cases that are impacted by the new design, and add additional test cases to handle the new design. They key is that I’m not writing unit tests to fit my design or testing at the very end when I have very little to no time, and there is too much to test. I’m writing test cases as I’m developing. This has a couple benefits: first, its faster to spot bugs that new code might be causing in older code because I have test cases for my older code, hence I’m not breaking old functionality. Second, when I unit test right after I’ve written a new component I’m forced to think about corner cases that might happen in the beginning of the development cycle rather than the end. This also improves the overall design of my code and the feature. If I have time prior to a release, I will add test cases as I fix bugs. This is how I’ve incrementally built up a regressions suite.
I think developers should face the responsibility of unit testing their code, instead of offloading all testing to QA. While you might not be able to think of 100% of the cases, flushing out simple error cases and thinking through a few corner cases at least handle some of the bugs that will come your way. Unit testing is not a substitute for integration testing, but given the time for system setup and tear down unit testing at least keeps pace with daily development. You can focus on integration testing once you’ve got the feature set completed, or also do it as part of your unit testing. The point is to consider the philosophies of testing, and try to adapt them to meet your needs. If writing test cases is the primary battle, focus more on meeting your teams developmental needs and less on being dogmatic about the current testing trends.
