.NET Musings

As a continuation of my last post, it’s time to actually implement the Specifications.  To do this, the framework I chose is Machine.Specifications, or MSpec. Aaron Jensen has ported RSpec over to C#, and made it available as open source on github here.  There isn’t a ton of documentation, but fortunately, Aaron has a LOT of sample code that helps the curious figure out how the framework does its work.

After getting the source, you will want to compile it.  If you use ReSharper, you will want to add it as a plug-in.  To do this, close all instances of Visual Studio, create the directory %Program Files%\JetBrains\ReSharper\v4.5\Bin\Plugins\MSpec and copy Machine.Specifications.*, Machine.Specifications.ReSharperRunner4.5.* from the compiled source into this new directory. If you do this, you will get the “LightBulbs” in the left rail of Visual Studio to run Specs with the ReSharper test runner in addition to getting support for viewing tests in the Test Explorer and running tests in the Test Sessions window.

I then created a new class library and referenced Machine.Specifications.dll, MbUnit.dd, Gallio.dll, and RhinoMocks.dll.  (You can plug in your unit testing and mocking frameworks that you prefer.) I then created a new class to write the Specifications. 

Note, this is a bit of a language shift here.  My interpretation of the mapping of terms goes something like this:

To refresh, the specifications that I came up with (granted, very trivial) are these:

Concern: Login

Context: When Logging Into the application with a valid user name and password

Observation: Should authenticate the user into the application
Observation: Should reload the user’s shopping cart should be from their last session

Context: When Logging Into the application with an invalid user name or password

Observation: Should not authenticate the user into the application

The process is very similar to what we do in TDD – write a failing test, pass the test, then refactor.  So we need to add the contexts into a class.  The “Concern” becomes the [Subject(“”)], the “Context” is the class name, and each “Observation” becomes an “It”.

using Machine.Specifications;
using MbUnit.Framework;
using Rhino.Mocks;
namespace MSpecSandbox
{
    [Subject("Login"), Tags("Login")]
    public class When_Logging_Into_the_application_with_a_valid_user_name_and_password
    {
        Establish context;
        Because User_Attempts_To_Logs_In;
        It Should_authenticate_the_user_into_the_application;
        It Should_reload_the_user_s_shopping_cart_should_be_from_their_last_session;
    }
    [Subject("Login"), Tags("Login")]
    public class When_Logging_Into_the_application_with_an_invalid_user_name_or_password
    {
        Establish context;
        Because User_Attempts_To_Logs_In;
        It Should_not_authenticate_the_user_into_the_application;
    }
}

A “translation” between traditional testing terminology and MSpec class bodies goes something like this:

There is a command line utility “Machine.Specifications.Console.exe” that will product HTML reports for the Contexts developed, and even lists the ones that are not complete.  This is a great benefit, since this now provides a vehicle to open the lines of communication between the development team and the non-development team.  The output for the above class looks like this:

This clearly shows what we are attempting to drive out through code, and also shows our status.  For the TDDers, “Not Implemented” == Red[Failed Test]. 

In this post we have setup the MSpec code, brought in ReSharper, and turned out handwritten Spec into code that we can report on and drive to completion.  In my next post, we drive the Specs to Green, refactoring along the way.

Happy Coding!