The 'External System Down' Test Pattern

Every complex enough piece of software does some sort of integration. And every point of integration is a point of failure waiting to happen, from the simplest network delay to larger scale horribleness. So, testing it all properly is quite often a great idea.

Conditions like what to do when one of those external systems comes down or becomes unavailable are a bit hard to spot in TDD’ed code, and in my experience become difficult to visualize in code and unit test form. And when I’m sitting there with images of train wrecks, mass murder and Britney Spears doing a cover of Stairway to Heaven, I want to be able to see things clearly.

One of the tools we recently reused at our current project was a testing pattern that proved itself very useful, making it possible to have all possible failure scenarios in one or two screenfuls.

We’re using a table like this (Foo and Bar are our integration points):

YNBar was unavailable.
NYFoo was unavailable.
NNFoo was unavailable.

You can add as many integration points as you like, and maybe some other variables or specific error conditions as well.

We’re using Fit, and it’s pretty easy to write a test to do that. Plus, we get 100% coverage (or find that we didn’t actually need to catch some exceptions), something otherwise difficult to achieve when not using higher-level test automation tools (and a whole universe of pain when doing manually).