Both you and I know it doesn’t, but Pattern1 – pull out state – could be read as recommending stateless behavior objects manipulating behaviorless state objects (i.e. procedures and records).
While the example is amusing (to my strange sense of humour), it’s could be a bit confusing. I’m assuming you’re separating out the concern of transforming the state of the world into an AppocalypseScenario from the concern of detecting the state of the world based on the environment, in order to make the transormation test simple. So how to address testing the state of the world detector? “StateMachine” is a bit confusing: it implies a state machine, but this wasn’t originally anything like a state machine – so have you done anything cool to make the detector more testable?

On pattern 4 – Whether you’re calling the workers via a pipeline, a batch process, or a unit test should be irrelevant to the workers involved. Once they’re tested, you can orchestrate your process however you want as long as it calls all the Action it gets given in the order you want with the envelopes it needs . But then I’d instinctively reach for a mock Action to test that …. hmmm.

Thanks! Appreciate the compliment!

Hi Paul, you bring up a good point. It is a bit beyond the scope of my example though. I probably should have included some code in this case.

Essentially the pattern I was tying to show here was something like:

for(x = 0; x < blah; x++)
{
var result = DoSomething(x);
Dependency.Use(result);
}

Can be refactored to:

List results = new List();
for(x = 0; x < blah; x++)
{
results.Add(DoSomething(x));
}

return results;

Essentially extracting the dependency by removing it from the original loop and storing the results of all the iterations of the loop into a structure that can be passed to a method that will use the dependency with the accumulated collection of results, so that the first loop can be unit tested easily.

This isn't always going to be efficient or present the best choice (for some of the reasons you stated above), but it will often allow for pulling out dependencies that look like they are tightly coupled to a process because of a loop.