lixo.org

It turns out it’s not that difficult to build event-driven systems, as Dan North brilliantly points out. We’ve all seen them, we’ve all built them, to some extent, and still a lot of developers I’m in contact with – one of the most terrifying examples being myself – go cross-eyed whenever highly concurrent application development gets mentioned.

Actually, concurrency is not the problem, but the fact that it gets in the way of my code and my business processes is. Using Dan’s example, I would still like to see the Pricer, Persister and Notifier queues in there somewhere, but away from those three lines where the process gets explained in simple “do this, then that” kinds of terms. I could show those three lines to a business analyst and get them validated – they still look reasonably like a set of tasks, in English.

If those queues could be made totally invisible, just like our dear garbage collectors, our world would be so much better, but I don’t believe our current languages are or can be made mature enough to support that without some pretty tough changes, though. Who knows, maybe LISP had that figured out decades ago and I’m just assuming incorrectly based on incomplete information – please correct me if that’s the case.

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):

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).