When writing some automation tests using Selenium with SpecFlow recently I was faced with an odd error:

    No matching step definition found for the step. Use the following code to create one:
    [When(@"I add a new dog")]
    public void WhenIAddANewDog()
    {
        ScenarioContext.Current.Pending();
    }

The suggested code was using a [When("My Scenario")] step despite the feature file declaring it as a Given:

Scenario: Check for existing dog
    Given I have a new Dog Controller
    And I add a new dog
    When I check if the added dog exists
    Then The check is true

(This feature is written badly to illustrate the error).

The step it couldn't find was the And I add a new dog step. Despite showing as bound in the feature file and being able to navigate to the step definition, the running test couldn't find it and was looking for a When instead of a Given.

This is because the previous step was calling sub steps as follows:

public class DogControllerSteps : Steps
{
    [Given("I have a new Dog Controller")]
    public void CreateDogController()
    {
        Given("I have a new query bus");

        When("I create a new dog controller");
    }
}

Inheriting from Steps allows us to reuse step definitions from the same or other step files.

When SpecFlow runs this it knows that it last ran a When step, despite being in the definition of a Given. Therefore when the next step is defined with And, it looks for a When. To fix this you can simply change your feature to be more specific:

Scenario: Check for existing dog
    Given I have a new Dog Controller
    Given I add a new dog
    When I check if the added dog exists
    Then The check is true

Passing tests :)

We recently started using CQRS on a project to provide a new web application to manage a complicated permit process. The CQRS pattern combined with a proper domain model seemed like a good fit for the business logic.

Midway through development of our 2 tier solution (Web <-> Database) we were asked to instead asked to develop a 3 tier solution (Web <-> Api <-> Database) to avoid exposing the database to the web server (no WCF allowed).

Initially the change slowed development and resulted in an explosion in the Lines of Code to functionality ratio. After some thinking we realised it might be possible to use Web API as a command/query bus for our pre-existing CQRS setup, effectively allowing us to "pass-through" the API without needing to write a controller action per command.

This post summarises the ideas behind the working approach we developed. All the code used in this post can be found on Github but the code is very obviously simplified; both to avoid revealing implementation specific details such as security and to allow this post to focus on the concepts.

CQRS

If you're not familiar with CQRS read some of the articles available on the advantages and disadvantages of the pattern. Basically you separate commands (actions which update data) from queries (which read data).

This post will only deal with implementing the query side of CQRS over Web API. Commands should be simpler.

Query and QueryHandler interfaces are defined in a separate CQRS class library (ideally Queries and Query handlers live in separate libraries because your web project shouldn't have to reference query handlers).

I recently finished the first release of my 2nd Nuget package which provides a class to convert an ADO.Net DataTable to a list of objects. This is the result of an effort to create a library for the conversion technique outlined in this post.

I've also created a Nuget package to help out with MVC 5 Radio Buttons located here.

This post summarises some things I learned from creating these Nuget packages.

Simplest package

For simply packing a class library targeting a single version of the .Net framework you can simply invoke the Nuget.exe with the path to the .csproj:

.\.nuget\NuGet.exe pack .\Path\To\Project.csproj -Prop Configuration=Release

If your solution doesn't have a copy of the Nuget exe in the .nuget solution folder you can download the exe separately.

This command will create the nuget package in the current directory with the metadata declared in the AssemblyInfo.cs for the project.

Creating a specification

The default nuspec specification file created by calling:

I recently watched Jimmy Bogard's excellent NDC presentation on Domain models to learn about how to implement a real world domain model.

One of the things Jimmy does in his presentation is to refactor his enum to use a base class allowing far more expressive enums with custom behaviour

There are a few versions of this custom enum base class around but I'm going to be using this one.

Annoyingly Entity Framework (EF) doesn't support mapping database fields to enums unless you use an int column in your database. This might be good enough for your implementation however it seems a bit fragile to couple your database to a mystery int defined in code somewhere which could be changed by any user who doesn't realise what they're changing.

For a marginally less fragile and more domain model friendly enum I used an adapted version of Jimmy's enumeration class:

The main change is to the DisplayName property. We add a setter because Entity Framework is only going to bring back the string display name and we need to map to the underlying value field to get the proper enum.

public string DisplayName
{
    get
    {
        return this.displayName;
    }

    // Entity Framework will only retrieve and set the display name.
    // Use this setter to find the corresponding value as defined in the static fields.
    protected set
    {
        this.displayName = value;

        // Get the static fields on the inheriting type.
        foreach (var field in GetType().GetFields(BindingFlags.Public | BindingFlags.Static))
        {
            // If the static field is an Enumeration type.
            var enumeration = field.GetValue(this) as Enumeration;
            if (enumeration == null)
            {
                continue;
            }

            // Set the value of this instance to the value of the corresponding static type.
            if (string.Compare(enumeration.DisplayName, value, true) == 0)
            {
                this.value = enumeration.Value;
                break;
            }
        }
    }
}

This simply checks the static fields on the instance of the enumeration class and finds the enumeration with the matching name.

We also change the private displayName and value fields to remove the readonly access modifier (and the underscores because I've never been able to adapt to the convention):

Update: the problem has been solved in version 2.0.0 of FakeItEasy.

I was recently facing an issue where my FakeItEasy tests were sometimes randomly failing. I'm specifying that it was the FakeItEasy tests because I managed to isolate to the failures to 2 tests which were using:

var thing = A.Fake<IInterface>();

The FakeItEasy fake would sometimes ignore the specified setup, such as:

A.CallTo(() => thing.Method()).Returns(true);

The fake would return false or null for reference types.

Analysing the stack trace on the failing test it was due to aggregate Exceptions occurring when running the tests in parallel. There is an issue describing this here.

We were using xUnit as our testing framework which runs tests in parallel by default. Unfortunately both FakeItEasy and Moq aren't threadsafe and this introduces bugs when tests are run in parallel. It seems like other testing frameworks also experience the same problem.

To get around this we disabled parallel test execution in xUnit. This means our tests take longer but are reliable.

If you've run into this issue before and found a better fix I'd be intrigued to hear it.