Testing When the Network Is Down

Contact us

Testing When the Network Is Down

Fill out form to continue
All fields required.
Enter your info once to access all resources.
By submitting this form, you agree to Expero’s Privacy Policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

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.

User Audience

Services & capabilities

Project Details

Technologies

Sebastian Good

January 31, 2012

Testing When the Network Is Down

Tags:

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.

User Audience

Services

Project Details

Similar Resources

Serverless ML

You can now deploy your models and get real-time scalable results without ever having to provision a server. Let me show you how I did it.

Watch Demo

Software Craftsmanship in Context

Software quality matters. Learn from a real use-case how we follow the Software Craftsmanship method to push a hard project forward.

Watch Demo

Company for a Cup of Joe: Finding Your Tribe

Combining traditional search techniques with graph algorithms to efficiently find subgroups within data.

Watch Demo

Testing React Applications Using Jest and React Testing Library

Avoid bugs & gain confidence when refactoring code by writing tests for your React code using Jest, React Testing Library & a Test Driven Development approach.

Watch Demo