Testing When the Network Is Down

Today I had the lovely experience of being told “the network to the cluster is down” while I was writing some code that was supposed to use the cluster. Was I stalled? How could I test my logic? It turns out we’re rather obsessive about separating interface from implementation, usually via C# interface definitions. In this case, I just went down the road I was going down anyway: making some simple mock objects to model the cluster dependencies. (We use Moq.) Now I don’t really care that the network is down.

People talk  about the usefulness of mock objects during unit testing quite a bit, but in my recollection they mostly emphasize two aspects

1. Mock objects are much faster, freeing you from waiting on databases and the like for testing your logic
2. Mock objects force you to concentrate only on the behavior of the class under test, making it a unit test

They’re right. But a third side effect, being able to be productive when parts of your system are missing, is just plain efficient.

Of course the cluster itself needs testing, and that’ll wait until we can talk to it. But today the component I’m building will still get built and debugged.

What was it? The event projector that processes domain events into a large simulator sitting on that cluster. Whether I tickle that simulator the right way can still be (mostly) tested without actually talking to it. And, as per numbers one and two, faster and cleaner than an integrated test would have been.