behaviour specifications

In the last few posts I've been exploring the use of a context specification style library for writing tests. This post continues on that vein with the user story I visited last time:

"As a user I want to view the current balance so that I can see the amount and date that it was captured."

I got as far as the first set of observations for a Balance class - a value object to hold the concept of a current balance. In order for me to deliver this story out to the UI I need a way to retrieve this data so the next step is a repository.
I create a new class called MemoryRepositorySpecification that will hold all the data access code for the time being (I can put a real implementation in later) and begin with the specification:

public class MemoryRepositorySpecification : 
    observations_for_a_sut_with_a_contract<IBalanceRepository, MemoryRepository> 
{ }

This time I'm using a different base class that enforces a contract - although I am testing MemoryRepository as my SUT, I can only test members that exist on the contract interface IBalanceRepository.

[Observations] 
public class when_a_current_balance_is_required : MemoryRepositorySpecification 
{ 
    [Observation] 
    public void should_be_able_to_provide_current_balance_from_the_memory_repository() 
    { 
       sut.GetCurrentBalance().should_not_be_null(); 
    } 
}

This is a very primitive test and simply asserts that a Balance instance does come back from the GetCurrentBalance() method I have just defined in my test.
When I put placeholder code in for this for compile, returning null the test fails so I then implement this by returning a Balance instance:

public interface IBalanceRepository 
{ 
    Balance GetCurrentBalance(); 
} 

public class MemoryRepository : IBalanceRepository 
{ 
    public Balance GetCurrentBalance() 
    { 
        return new Balance(10.5, DateTime.Now); 
    } 
}

I now have a basic repository implementation and a Balance class - this is purposefully as basic as possible but is still written as production code until I later swap out the data access object.
I now need to define my presenter and view for display in the UI where a webform page will implement the view.

I start with a new folder in my Plutus.Core project "Presenters" and add the "BalancePresenterSpecification" class in here. This will define my presenter and the logic I want to begin with is that during an Initialise call to the presenter, the current balance will be obtained. Being dogmatic, this is actually an assumption on the user story (that the current balance needs to be obtained when the view/page loads/initialises) but suits my purposes for this exercise.
My first step is the specification class, declaring the SUT as a new BalancePresenter class:

public class BalancePresenterSpecification : 
   observations_for_a_sut_without_a_contract<BalancePresenter> 
{  }

I then write my observation:

[Observations] 
public class when_creating_a_balance_presenter : BalancePresenterSpecification 
{ 
    private static IBalanceView mockBalanceView; 

    private context c = () => 
                            { 
                                MockRepository mockRepository = new MockRepository(); 
                                mockBalanceView = mockRepository.DynamicMock<IBalanceView>();  
                                // note that these lines above change later in the post 
                            }; 

    [Observation] 
    public void should_be_able_to_provide_a_balance_view_and_a_balance_repository() 
    {            
        BalancePresenter balancePresenter = new BalancePresenter(mockBalanceView, 
                                                  new MemoryRepository()); 
    } 
}

Here I am setting up a context for my observation using one of the "Arrange" parts of the context specification library - the static context delegate. This is a delegate simply declared as follows:

namespace developwithpassion.bdd.contexts 
{ 
    public delegate void context(); 
}

During the test run the context is run before the SUT is set up and all contexts are identified and run (if you had one on base class and on sub class for example). In my context I am using a lambda expression to declare an anonymous method that creates a mock object implementing a new IBalanceView interface - I use a mock object rather than a stub (that I would manually create) so that I need not concern myself with future changes on that interface... the mock will take care of it on my behalf.

All that is needed now is to create IBalanceView interface (and move it to a "Views" folder) and create the constructor for the BalancePresenter, both really easy with a few Resharper key-strokes:

namespace Plutus.Core.Views 
{ 
    public interface IBalanceView 
    { 
    } 
}

public class BalancePresenter 
{ 
    private IBalanceView balanceView; 
    private IBalanceRepository balanceRepository; 

    public BalancePresenter(IBalanceView balanceView, IBalanceRepository balanceRepository) 
    { 
        this.balanceView = balanceView; 
        this.balanceRepository = balanceRepository; 
    } 
}

Note that I've jumped straight into implementing this code rather than red-green-refactor process as it is fairly straightforward and easier to illustrate on a blog post.

Now for some clean up and some better syntax - I've put my initial version of code that I wrote using traditional Rhino Mocks code to mock out the IBalanceView interface and provide a proxy.
Here is a better way of doing so using the bdd library:

[Observations] 
public class when_creating_a_balance_presenter : BalancePresenterSpecification 
{ 
    private static IBalanceView balanceView; 

    private context c = () => balanceView = an<IBalanceView>(); 

    [Observation] 
    public void should_be_able_to_provide_a_balance_view_and_a_balance_repository() 
    {            
        BalancePresenter balancePresenter = new BalancePresenter(balanceView, 
                                                new MemoryRepository()); 
    } 
}

I've removed the need for a MockRepository instance by using the "an()" method on the base observation class. This wraps generating a stub using the static method in RhinoMocks:

static public InterfaceType an<InterfaceType>() where InterfaceType : class 
{ 
    return MockRepository.GenerateStub<InterfaceType>(); 
}

It is an excellent naming convention for mocking interfaces that begin with an "I" and reads well. Note that in this new version I don't feel obligated to call is "mockBalanceView" anymore as I'm not directly interacting with the mock repository (you could argue that I was never obligated! But this expressive syntax definitely cleans the code up in my experience).

Also of note is that I've also customised the library at a later date to provide a mock version:

static public InterfaceType aMockOf<InterfaceType>() where InterfaceType : class 
{ 
    return MockRepository.GenerateMock<InterfaceType>(); 
}

Now I'm about to invalidate the main code in this post by saying that all of this it isn't actually required.

The contract on the constructor is already handled by the code wiring up the sut behind the scenes - I need never therefore put this type of code in. However I want to clearly express what the dependencies are in my test output and therefore have this "should be able to provide a balance view and a balance repository" specification available.
It also helped me test drive the code using Resharper and does no harm in sitting there, save the possibility of review when the constructor changes.. but again I would test drive from this specification.
It also leads very well into the next blog post I will be writing on exception expectations so remains part of my test suite at present.

Perhaps when I'm much more comfortable with behaviour driven development I'll only have real behaviours as my specifications and not contract ones already enforced by the compiler.



0 comments: