The Quantum Mechanics of Unit Tests

Have you ever had someone from QA come up to you and say something like "Screen X isn't saving data anymore"? And then you say something like "What the hell???" because you are sure that nothing has been touched in that part of the app for weeks? Not only that, it was working perfectly the last time you were there. P-E-R-F-E-C-T-LY. I swear! I mean, just look in the database. There is data in there. And it came from that screen.

I know some of you know what I am talking about. I have experienced this many times. For some inexplicable reason code that was fine now seems to have actually physically decayed on my hard drive somehow...like a corpse in July...in Houston no less!

Those of you who have no idea what I am talking about or maybe relate to what I am saying in some sort of distant, primordial, genetic memory kind of way, have probably been doing TDD. Or at least writing lots of unit tests around your code.

I have finally reached the point where I can say with absolute certainty that I am almost doing TDD. I am writing unit tests a lot and sometimes those unit tests affect my design. Sometimes I write the test first, like I am supposed to do. And sometimes I don't, but my code is testable nonetheless. In the end, I do have unit tests all over the place. I'm talking solid coverage, too. State-based tests. Interaction-based tests. Stubs. Mocks. Fakes. You name it, I got it.

So, today, we had to jump into some code that is WEEKS old. In the past, the code would just break (of course) if only for the mere fact that we looked at it. Like when you go to the doctor and everything is fine, but when you leave, you have cancer. Anyway, everything worked. And I mean, it worked great. I am convinced that unit tests are to bugs what garlic is to vampires. It's like the unit tests observe the code, so you can go look at something else, and thereby Schrödinger's cat gets to live.