This isn’t going to be news to most developers, but I just thought I’d write this down anyway.  I was talking with a colleague yesterday about unit testing, and about RhinoMocks in particular, and came up with what I thought was my best explanation to date about why Mocks are important.  To me, it all came down to the following sentence.

It’s that "assuming … job" part that’s important.  That’s what the mocks or stubs are for.  They’re the tool that lets us focus a test on a single piece of code, excluding as much of the outside world as possible.  That’s what makes unit testing work.  We’re not saying that the code "over there" won’t be tested as well.  It just won’t be tested "here".  Having a separate test for "here" and "there" rather than one overall test for both means that if one of the two pieces break in the future, then we’ll know which one it was.  We’ve cut our number of suspects in half by testing them separately.

 

Talking about this reminded me of a problem a theatre director once explained to me.  It’s all about vocabulary.  The problem isn’t usually that people can’t understand what you’re trying to get them to do, it’s that you haven’t put it in the right terms for them.  You can give the same instructions to three different actors, and each one will do something slightly different.  Getting people to really grok what you’re saying relies entirely on finding the words that mean the same thing to them as the concept you’re explaining means to you.

 

Like I said, if you "get" unit testing, then this post isn’t anything you don’t already know.  But maybe if you’re just getting into the idea, or if you’re the type who argues for integration testing because it’s closer to "real world" conditions, then maybe my explanation might change your mind about how you think about testing.