When I started at Google last year, I was really impressed by their testing. Every C++ class had three files: a <classsname>.h file, a <classsname>.cc, and a <classname>_test.cc. Every time something new is implemented, it has to be tested. The code review tool even warns you if you add a new .h without an accompanying _test.cc.
The upside to this is that I am very sure that my code does what I want. There are, of course, still bugs, but generally they’re of the “I hadn’t thought of that case” rather than the “I didn’t implement it the way I meant to” variety.
A side effect is that writing tests forces a decent separation of concerns. If you’re throwing around singletons and hiding twenty layers of functionality in a class’s privates, you’re going to have a bad time. Conversely, if you’re making things testable, each class essentially becomes a wrapper for the resource below it: “I take a database connection and add some query logic,” “I take a storage wrapper and add some app-specific logic,” “I take app responses and present it to the user.” The whole application falls into beautiful, simple layers like a mille-feuille cake.
The downside is that writing tests is so. slow. It often takes me three times as long to write a test than it did to write the code. I think that, if you’re working at a startup, it’s actually probably not a good idea to have a culture of testing like this because it will slow down your coding so much. For most startups, getting something to market in 33% of the time that 90% works is much more important than getting it to 99%. In fact, Google hasn’t always had this culture. If you look a the dark corners of the code base, there are tons of old, untested classes.
I count myself as lucky to know the guy who actually inspired the testing culture that Google has now: Mike Bland. He’s been writing a series of articles on testing for Martin Fowler’s site. If you’re interested in testing, I recommend reading them.
Kristina Chodorow's Blog 