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):
|Y||N||Bar was unavailable.|
|N||Y||Foo was unavailable.|
|N||N||Foo 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).