Scenario: New password min length
    Given I have entered a password with only 5 characters
    When I hit save
    Then I see a validation error against password

So, first off I’m going to need to simulate a value being posted to an action method in the form collection. The simplest approach would be something like this…

[HttpPost]
public ActionResult ResetPasswordSubmit(string password)
{
}

However, it doesn’t really feel right to put the business rules around password validation directly in to this action method, as there may be other places in the application where a user can change their password. A better approach would seem to be implementing the validation rules as Data Annotation attributes against the model class. The method then becomes something like this…

public class SecurityController : Controller
{
   private readonly ISecurityService securityService;

   public SecurityController(ISecurityService service)
   {
      this.securityService = service;
   }

   [HttpPost]
   public ActionResult ResetPasswordSubmit()
   {
      var user = this.securityService.GetSignedInUser();

      if (this.TryUpdateModel(user, new string[] { "Password" }))
      {
         // save user
      }
   }
}

Working with a model class that looks a bit like…

using System.ComponentModel.DataAnnotations;

public class User
{
    [StringLength(20, MinimumLength = 5)]
    public string Password { get; set; }
}

So what would happen now is that the browser would post a single value in the form collection (Password). When TryUpdateModel is called, the framework will use a model binder to map the request information onto the model properties. The model binder to use can change according to the type being mapped, but in this case the DefaultModelBinder will be used.

The model binders need to make use of information from the request (such as posted form values, querystring etc). Value Providers provide an abstraction around this, and the framework ships with various providers to interrogate the different types of request information. In our example, the FormValueProvider would map the Password value from the form collection onto the Password property of our model class. As part of this process, the DefaultModelBinder will apply any validation rules set up via Data Annotation attributes, and add any validation errors into ModelState.

Time to get started with our unit test. With SpecFlow, the scenario is defined in a plain English language based on the Cucumber DSL. When you save the scenario, Specflow will generate a test fixture that includes a test method with the scenario name – in our case NewPasswordMinLength. The test method will attempt to call a method for each individual step in the scenario based on binding attributes applied to the methods.

We can start by adding a new item, and picking Specflow Step definition. To map the scenario steps in our example would like this…

[Binding]
public class ResetPasswordSteps
{
    private ActionResult result;
    private readonly Mock<ISecurityService>;
    private SecurityController controller;
    private User user;

    [BeforeScenario]
    public void BeforeScenario()
    {
       this.securityService = new Mock<ISecurityService>();

       this.controller = new SecurityController(
          this.securityService.Object);

       this.user = new User { Id = 1 };
       this.securityService
          .Setup(s => s.GetSignedInUser())
          .Returns(this.user);
    }

    [Given(@"I have entered a password with only 5 characters")]
    public void GivenIHaveEnteredAPasswordWithOnly5Characters()
    {
        ScenarioContext.Current["Password"] = "Foot";
    }

    [When(@"I hit save")]
    public void WhenIHitSave()
    {
        // todo: simulate the form value being posted
        this.result = this.controller.ResetPassword();
    }

    [Then(@"I see a validation error against password")]
    public void ThenISeeAValidationErrorAgainstPassword()
    {
        var view = this.result as ViewResult;
        Assert.IsNotNull(view);
        Assert.AreEqual("ResetPassword", view.ViewName);
        Assert.IsFalse(view.ViewData.ModelState.IsValidField("Password");
    }
}

First we set define a method decorated with the BeforeScenario attribute. This is a Specflow attribute that indicates the method should get executed before each scenario. This can be used to carry out any initialisation required. In this case, I’m mocking the SecurityService dependency and setting it up to return a dummy User object when the GetSignedInUser method gets called.

Executing the NUnit test would evaluate each step in the written scenario, discover these methods based on the binding attributes, and execute them in turn. Any state information that needs to be preserved can be either stored in private fields or on the  ScenarioContext object.

The bit missing is how to simulate a form value being posted in the unit test. Remember the binders will use ValueProviders to get information from the request, so this is the piece we need to mock or simulate. To get this working, we would need to add the following code…

[When(@"I hit save")]
public void WhenIHitSave()
{
   var form = new FormCollection
   {
      { "Password", (string)ScenarionContext["Password"] }
   };

   this.controller.ValueProvider = form.ToValueProvider();
   this.result = this.controller.ResetPasswordSubmit();
}

Here we are using the FormCollection class to simulate values being posted, and setting the controller to specifically use this value provider for binding scenarios, instead of the default set of providers.

At this point in time, we get a null reference exception running the test, as TryUpdateModel assumes that the ControllerContext property on the controller is available. To get the test working we need to mock this, so back in our initialisation method we add a few lines…

public void BeforeScenario()
{
   this.controller = new SecurityController(this.securityService.Object);

   var httpContextMock = new Mock<HttpContextBase>();

   this.controller.ControllerContext = new ControllerContext(
      httpContextMock.Object,
      new RouteData(),
      this.controller);

   this.user = new User { Id = 1 };
   this.securityService
      .Setup(s => s.GetSignedInUser())
      .Returns(this.user);
}

That’s all we need. To recap…

• We started by writing a plain English scenario in Specflow
• We created a class to contain the step definitions and added binding attributes to map the Specflow scenario steps to the right methods
• We added a method to run before the scenario to initialize the controller, mock the dependencies and provide a ControllerContext
• In the WhenIHitSave method, we initialized a FormCollection with simulated form values and set the ValueProvider on the controller to make use of this
• In our ‘Then’ method we assert that the view was returned with a ModelState error against the Password field
• The end result is an executable acceptance test (by default this will be NUnit unless Specflow is configured otherwise)

All mocking examples have used Moq which is awesome.

Obviously there are solutions to this problem, the foremost being to set up a project wiki. However I’m quite fussy about design and interaction, and the way that software feels when you use it, and I’ve yet to find a wiki product that makes me feel good. I want something that is addictive and satisfying to use, that engages you and makes you want to work with it. The idea being to build a multi-tenant application that can host project knowledge for teams.

Based on this I’ve started work on TeamBrain, hosted on Codeplex. Feel free to grab a copy of the source and talk to me as it develops. I have some time off work so will be trying to flesh it out over the next few weeks.

I’m also taking the opportunity to try out a few new technologies and things I’ve wanted to take a look at for a while. The one I’m most excited about is BDD (Behaviour Driven Design). I’ll be running the project by defining features and scenarios in SpecFlow, and having all of the unit tests and behaviour pulling from the defined scenarios. If you want to learn more, I suggest starting with this screencast which gives a really great introduction. I’ll post some examples and hints as I learn along the way.

I’ve been waiting a while to for the updated edition of C# in Depth by Jon Skeet which is now on sale and covers C#4. I’ve read the first couple of chapters and would really recommend it regardless of how much experience you have with C#. It’s already helped me with some very clear explanations for concepts that can be a little tricky to express even if you understand them already. One particular explanation that I liked was to distinguish between delegate types and instances, and to think about a delegate type as an interface for a method – so a contract that the method has to fulfil. I’m quite sure that there will be a lot that I’ll get out of reading the rest of the book.

CSS3 For Web Designers by Dan Cederholm

This is the second book to be published by A Book Apart and should definitely be worth checking out. I think it will really help to provide practical advice about where you can safely start applying elements of CSS3 right now. I’ll post more when I’ve got hold of a copy.

However in this instance I’m working with a large legacy codebase. Even with the best intentions people won’t stick to a convention unless it gets enforced, and based on the amount of code that doesn’t comply it isn’t very simple to start enforcing the standard.

The only solution I could really see was to swallow the pain and go and reformat all of the existing code, then start enforcing analysis on the projects that have been updated.

I don’t think this would have even been possible if it hadn’t been for Resharper 5 and the StyleCop for Resharper plugin. I’ve become massively more productive since using Resharper a few weeks back and in this instance it’s been simply awesome.

Code Cleanup

Once Resharper has been configured with the StyleCop plugin so all coding style conventions are set up, you can run the code cleanup feature against a file or folder (Ctrl-Shift-Alt-F) which will reformat all existing code based on the configured rules. In my case this will typically reduce a file from around 300 violations to about 8. You can set up a profile to control exactly what does or does not get changed as part of this process.

Cycle through code issues (F12)

The next most useful feature is that StyleCop violations are treated as code issues by ReSharper. Hitting F12 repeatedly within a code file will jump to the next issue making it very simple to navigate around all violations and clean them up.

Violation highlighting within editor

The plugin will also highlight any style violation as you code, and provide tooltips and messages in the status bar to indicate what the violation was.

It will still take a while to finish updating the existing codebase, but I’m not even sure it would be feasible to attempt this without these tools.

This fits in very nicely with some of the ideas in Behaviour Driven Design, which is like the next iteration of thinking around TDD. The idea is to express acceptance tests using a simple DSL vocabulary working in plain English, then hook up each acceptance test scenario to some automated tests which prove the scenario works as expected.

A simple example would be…

+Title: Customer withdraws cash+
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.

In BDD, an acceptance test would be along the lines of…

+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned

I’ve lifted the example here from the key article published on BDD from Dan North – if you’re interested so far then you should stop reading now and go and check out the article.

BDD frameworks will then map each step expressed in the text above through to a method in a test class, so you have a great balance between expressing the acceptance tests in simple language, but having the ability to execute the tests.

I found the best way to learn about this so far was a TekPub video – you’ll need a subscription, but the video is under the ‘Concepts’ section > Concepts:5 Behaviour-driven Design with Specflow.

Overall it seems like a more natural way to approach proving the application behaviour, and makes it much easier for testers and analysts to work alongside you in defining acceptance tests. I’m quite keen to roll this into our day-to-day process.