Clay Dowling's Occasional Musings
I'd love to say that I'm gonna be a power blogger with lots of important stuff to say, so that I could promise weekly or even daily postings. The reality is that I'm a dude with a job and a family and too many hobbies, so you'll get posts when I really have something to say. Occasionally they'll even be worth reading.
We've all seen code bases that look like they might have been written as an ode to Fear and Loathing in Las Vegas. There's a good chance that we have even perpetrated such code. But now it's in production and the support is making you wonder why you didn't take that nice accounting job out of school. You could put tests on the code but it's such a mess that you should probably just throw it out and start fresh, if only you had the time and the Business wasn't howling about the way the software is causing them to bleed cash. Fear not, there are strategies that can help you out.
One problem a lot of people run into is the need to test code that uses APIs they don't control. This came up tonight during a discussion on mocking at the Pillar Technology Plugged In event in Ann Arbor. The system in question was a remote service, but I encountered it recently with UNIX system calls. Fortunately there's a simple solution.
If you wrap the APIs in a class, you can mock that class. I'll show you an example from my own project, written in C++. The first step was to create an interface. In classes that need to access this API, they will declare a member which is a pointer to that interface.
If you have even a moderately complex application, writing tests can be a real pain. You either wind up writing complex, fragile tests, or you skip it altogether. There is a third path: fake out all of the parts that you aren't testing in this test. You can examine the fake parts to see what has been done with them, and you can make them respond however you want to your program.