Now that i have presented a simple ControlStateMachine i can raise the bar a little. A statemachine that handles commands. Here is how a developer should be able to initialize this machine:

sut.WhenIn(States.Loading)
 .On(Commands.Next)
  .Do(() => Console.WriteLine("got next command while loading..."))
  .Do(() => Console.WriteLine("doing it again..."))
 .On(Commands.Previous)
  .Do(() => Console.WriteLine("got previous command while loading..."));

sut.WhenIn(States.Ready)
 .On(Commands.Previous)
  .Do(() => Console.WriteLine("got previous command while ready..."));

So how should we define our methods to accomplish this initialization style? Let’s begin with identifying the methods we need.

• WhenIn(TSTate state)
• On(TCommand command)
• Do(Action action)

Next thing to do is analyze in which sequence these methods can be called:

Ok, now that we have clarified the requirements a little we can start working on a solution. Let’s start with defining an interface for each of the methods:

interface IChooseState<tstate, TCommand> { Q1 WhenIn(TState state); }
interface IChooseCommand<tstate, TCommand> { Q2 On(TCommand command); }
interface IChooseAction<tstate, TCommand> { Q3 Do(Action action); }

From WhenIn we need to be able to call On. Thus Q1 = IChooseCommand<TState, TCommand>. Q2 is also easily solved because from On we only have to be able to call Do, thus Q2 = IChooseAction<TState, TCommand>.

From Do we should be able to call both On and Do. We can do that by defining another interface which has both methods:

interface IChooseCommandAndAction<tstate, TCommand> : IChooseCommand<tstate, TCommand>, IChooseAction<tstate, TCommand> { }

Now that we have found answers for Q1, Q2 and Q3 we can define the API for initializing our StateMachine as following:

IChooseCommand<tstate, TCommand> WhenIn(TState state);
IChooseAction<tstate, TCommand> On(TCommand command);
IChooseCommandAndAction<tstate, TCommand> Do(Action action);

Now tell me about your strategy for implementing a fluent interface!

As you can read in CA1001: Types that own disposable fields should be disposable. Pretty solid advice, but for some reason the mstest runner does not dispose of classes that implement IDisposable. A possible workaround is to apply a TestCleanupAttribute to the Dispose method, but this is really contradictory with the “Shared test fixture” approach mstest uses. Imho, there is only one clean solution: use a decent testing framework instead.

Here are a couple of reasons why i dislike the Unit Testing Framework that comes with Visual Studio Team System:

• Not all versions of Visual Studio are capable of running the tests.
• Test inheritance is not supported.
• Running tests via mstest.exe is slow.
• Visual Studio creating tens of .vmsdi files.

There are already a couple of better frameworks out there, and currently MbUnit is my favorite one, certainly in combination with TestDriven.NET.

I have created a custom implementation of the Microsoft.VisualStudio.QualityTools.UnitTestingFramework assembly. Actually, the assembly only has a couple of Attributes for the moment but contributions are always welcome

In order to achieve better performance i decided to implement a custom test runner. Currently Gallio uses mstest.exe but there might be a day that i decide to write a plugin so that mytestrunner can be used instead.

I was inspired by Creating Self-testing Assemblies and decided to use that approach but for some odd reason visual studio insists on running unit tests although the assembly is a console application Anyway, i can still invoke mytestrunner via the external tools as following:

The source code is available at http://code.google.com/p/mytestrunner/.

After reading The Compare Contract last week i realized that my templates for int and string ValueObjects did not comply with the contract so i decided to add a unittest that reproduces the faulty behavior (and then corrected the implementation):

/// <summary>
/// When comparing instance with null, instance should be greater.
/// </summary>
[TestMethod]
public void ShouldReturnPositiveWhenComparedWithNull()
{
 $classname$ value = new $classname$("0");
 Assert.IsTrue(value.CompareTo(null) > 0);
}

Anyway, feel free to download the corrected IntValueObject and StringValueObject templates.