Adventures in TDD – fillin’ a hole in the SignalCommandMap

A simple question: What did you have for breakfast this morning?

Me? I had toast. 2 slices, white, with Flora and some great peach jam that we brought back from Spain.And a cup of tea, white with 2 sugars.

Another question: What didn’t you have for breakfast this morning?

Me? I didn’t have oatmeal. Or eggs. Or a hippopotamus, or lego, or chainsaw oil. The list of things I didn’t have is endless. Literally endless.

It’s impossible to fully scope the list of things that something doesn’t do, and yet as developers it’s important that we don’t just know what our code does, we also know what it doesn’t do.

Maps, maps and more maps

Over the last few months I’ve knocked up a few specialised ‘maps’ for working with robotlegs. I like the ethos behind these kinds of utilities – abstracting the meta-logic (the nature of the problem being solved) away from the detail-logic (the specific solution).

I’d planned to blog each one in turn, but the time runs away so quickly doesn’t it?

And so – all in one fell swoop – I offer you 3 variations on the CommandMap, a SignalMap and a race-condition beating EventMap. All on github and created through Read-Me-Driven-Test-Driven-Development, so you should find the ReadMe in each case sufficient to get going, but do check out the diagrams in this post as well:

GuardedCommandMap – for separating conditions from actions
OptionCommandMap – for implementing user options
CompoundCommandMap – for triggering a command in response to a combination of events
SignalMediator (containing SignalMap) – for automatic cleanup of signal handlers
RelaxedEventMap – for beating race conditions