In my last Automation Framework post I asked for some advice on managing state between commands. I didn't get any public feedback on the blog, but an old college of mine named Jon Lester tinkered with the blogged examples and sent me some of his code. The nut of his idea was to use extension methods on an accumulator object to separate the domain logic from the testing apparatus. I liked his approach, it wasn't something that would have popped into my head; it also put a spotlight on a simple and elegant solution to my state sharing problem.
Before I dive into Jon's idea, take a look at how I'm currently sharing state between my command objects:
//...
UserAccount account = new UserAccount();
CompositeCommand cmd = new CompositeCommand(
new LoadUserAccountCommand { UserName = userName, Account = account },
new MakeDepositWithTicketCommand { Amount = depositAmount, Account = account }
);
bool result = cmd.Execute( context );
// ...
This example represents a single task on the system under test - specifically making a deposit into a user account. The task effort is distributed across the LoadUserAccountCommand and MakeDepositWithTicketCommand objects, which must share a common Account object in order to accomplish the ultimate goal.
As I described previously, I like this approach okay, especially compared to some of the alternatives I've tried. I think it's simple enough to understand, but at the very least, it requires some explanation which is an API FAIL. And although you can make it work for value and immutable types, it takes an ugly hack.
My college's solution was to isolate the shared states from the commands, and expose the units of work in a fluent interface wrapping the shared state. I whittled down his approach into a lean and clean interface - here's an example of the end result:
// ...
Execute.Using( context )
.ForPlayer( account )
.Deposit( 500m );
// ...
Same unit of work, but a lot less code and far easier to understand IMO.
Implementation
The root of the fluency is implemented in the Execute class, which encapsulates a command context (which I describe here):
public class Execute
{
IContext context;
private Execute( IContext ctx )
{
context = ctx;
}
public static Execute Using( IContext context )
{
Execute e = new Execute( context );
return e;
}
public AccountCommands ForPlayer( Account account )
{
return new AccountCommands( user, Process );
}
public GameCommands ForGame( Game game )
{
return new GameCommands( game, Process );
}
bool Process( ICommand[] commands )
{
foreach( var command in commands )
{
if( ! command.Execute( context ) )
{
return false;
}
}
return true;
}
}
As you can see, the only inroad to this class is the Using method, which returns a new instance of the execute class initialized with the Command Context. The various flavors of the For() method are used to capture the shared state for a set of commands. They each return a object supporting a redundant, fluent interface of commands around the state. For example, here is some of the AccountCommands class:
public class AccountCommands
{
Func< bool, ICommand[] > processCommands;
public AccountCommands( Account account, Func< bool, ICommand[] > callback )
{
processCommands = callback;
this.Account = account;
processCommands(
Chain(
new LoadUserAccountCommand { Account = Account },
new CreateUserAccountCommand { Account = Account }
)
);
}
public Account Account { get; set; }
public AccountCommands Deposit( decimal amount )
{
processCommands(
new MakeDepositWithTicketCommand {
Amount = amount,
Account = account
}
);
return this;
}
public AccountCommands Withdraw( decimal amount )
{
processCommands(
new MakeWithdrawalWithTicketCommand {
Amount = amount,
Account = account
}
);
return this;
}
public AccountCommands SetProperties( Hashtable properties )
{
processCommands(
Compose(
new LoadAccountPropertiesCommand {
Account = account
},
new SetAccountPropertiesCommand {
Properties = properties,
Account = account
}
)
);
return this;
}
// etc ...
ICommand Chain( params ICommand[] commands)
{
return new ChainOfResponsibilityCommand(
commands
);
}
ICommand Compose( params ICommand[] commands )
{
return new CompositeCommand(
commands
);
}
}
Items of note:
- The constructor accepts two arguments: an Account object that represents the state shared by every member of the class, and a Func<> delegate that accepts an array of command objects and returns a boolean;
- Each public method of the class represents a single task one can perform against an account;
- Every public method simply composes one or more Command objects, which are passed to the processCommand callback for actual processing.
Huge Bennies
It still needs some work, but there are many things I like about this approach. The thing I like most is that the fluent interface hides the complexities of composing command objects with shared state to perform system tasks. I get all the benefits of the command pattern with minimal hassle.
With a bit of refactoring, I can easily reuse the *Commands objects from this fluent interface to do things besides execute the task. E.g., perhaps I want to build up a system scenario and persist it, something like this:
var commands = new List< ICommand >();
BuildUp.Into( commands )
.ForEachAccount
.Deposit( 500m )
.SetImage( PlayerImages.Face, testBitmap )
.SetProperties(
new {
Address = "12 Main St.";
City = "Anywheretownvilleton"
State = "Texhomasippi"
Zip = "75023"
}
);
// now the commands variable contains the defined
// command structure and can be re-used against new
// players in the future, persisted to disk, etc.
Another big benefit of this approach is that it gives me a stable binding point for PowerShell - and by that I mean that I can deeply integrate this automation framework with PowerShell, leveraging all of the built-in freebies with virtually no effort. But that is another post...