Unit Testing and Mock Objects

Posted on June 23, 2012 by concept47

Recently, I’ve been working hard to plug one of the biggest holes in my game … testing. I stumbled across this article, which helped make a lot of things clear for me, with respect to mocking and its relation to Unit testing.

This is partially due to the fact that most geeks don’t actually know what a unit test is. They think that testing the methods of a specific class constitutes a unit test, but that’s only part of the story. A unit test test is when you test the methods of a specific class in isolation, and the difference is critical. You know how some people call us “computer scientists”. Yeah, well this is the science part.

If you’re not doing this, you are not unit testing. That’s not meant to deride what you’re doing. I mean that as a literal statement of fact. Anyone, for example, who is using the built in Rails “unit” testing framework with fixtures (or FactoryGirl fixtures) is guilty of this. No test that relies on a separate class, or API, or interfaces with a database in any way is a unit test. It is an integration test (some people call them functional test), and when something goes wrong it is just a matter of time before it misleads you.

Enjoy the article – The Thing about Mock Objects

Sit down and write two letters …

Posted on June 22, 2012 by concept47

There’s a story from this one scene in the interminably brilliant movie ‘Traffic‘ which I have never been able to forget (I went and found it on imDb).

You know, when they forced Khruschev out, he sat down and wrote two letters to his successor. He said – “When you get yourself into a situation you can’t get out of, open the first letter, and you’ll be safe. When you get yourself into another situation you can’t get out of, open the second letter”. Well, soon enough, this guy found himself into a tight place, so he opened the first letter. Which said – “Blame everything on me”. So he blames the old man, it worked like a charm. He got himself into a second situation he couldn’t get out of, he opened the second letter. It said – “Sit down, and write two letters”.

I’m not a very funny guy, but everyone I tell that story to, laughs … a lot

Recently, I’ve been thinking about it a lot in relation to software development. A few times in my career, I’ve come across a codebase that I thought was horrible/ridiculous/over-engineered/whatever, and my first reaction as a young developer was to ridicule or berate the the previous developer, loudly.

The funny thing is that it actually worked, initially anyway. The client was usually apologetic and cut me a lot of slack on deadlines and estimates. Then as I started to work on the code, I would begin to see why the developers made some of the decisions that they did. Maybe their pointy haired boss keeps pushing to get things done faster than is realistically possible, forcing the developer to write smelly code just to get done (“I’ll come back and fix it later!”), or there is some bureaucratic technical constraint that forces you to do things that appear very stupid at first glance. Sometimes, even, the developer was more advanced than I was and I couldn’t understand what they had written initially, so I just labeled it ‘overly complex’ because I couldn’t figure it out in one sitting.

The moral of the story is, professional courtesy matters. Always give the person that went before you the same kind of benefit of the doubt that you’d want someone coming after you to have for your work. Badmouthing the code you’re working on, can come back to bite you in the ass when you become its undisputed owner. Be slow to do it, and if you must speak ill of the dead (so to speak), then be respectful, unless they absolutely deserve it (this is rare).

You see, the client/your boss will usually give you the time and resources to fix up the code, so you only get to blame the old guy for so long. Eventually, the question becomes “Why does the code still suck after all this time that you’ve been working on it?”. If you can’t answer that satisfactorily, you might find yourself out of a job, and who knows what the next guy is going to say about you?