Testing. For most developers, it lurks like a cancer in the back of our brains. You know you should be writing tests, and you should be writing them now, but… well, let me just get this thing working first. At RailsConf I attended several talks, and a tutorial, on testing. While I didn’t get much in the way of concrete knowledge to get started writing tests, I did drink the testing Kool-Aid and I am on my way to becoming a Test Driven Development/Behavior Driven Development advocate.

All of that said, I don’t have enough experience writing tests to be an expert, but this conversation I had today seemed worthy of sharing. When do you use a mock. I uttered a phrase that received a lot of head nods towards the tail of the conversation:

“Mocks are bug aggregators”

If you decide to use mocks in your testing, you are essentially saying “I have no way of testing this for real” or “This is too hard/time consuming/boring right now”. That isn’t to say that mocks dont have their uses, like mocking data that comes to or from a remote system, but they don’t actually test true functionality. If they did, we wouldn’t call them mocks.

What a mock does is create a choke point for aggregating bugs. If you don’t have time to write tests for part of your system, you can mock it, and then when bugs arise that slip past your tests, you have a good idea where to start looking. Of course, good little programmer girls and boys will write tests instead of mocks, but sometimes reality usurps idealism.