I just created my first Nuget package

… and it was really easy!

I thought that it might be difficult to publish a package on Nuget or I’d have to pay to do so.

I used the Nuget Package Explorer GUI tool and followed these simple instructions, then registered for free and published my package in under 5 minutes – easy.

What did I create, I hear you ask? Well its an extension method that takes a dictionary and returns an ExpandoObject.

You can get the package here and the code here.

Specification test patterns – reprise

In my previous post, I mentioned I could improve the readability of test classes that require a single context for all assertions. The solution is to use Fixie.

Before Fixie

public class When_I_initialize_People_with_text_that_includes_invalid_data
    : IClassFixture<When_I_initialize_People_with_text_that_includes_invalid_data.Context>
{
    public class Context : Context
    {
        public Context()
        {
            SUT = new People { 
                "{\"firstName\":\"John\", " +
                "\"lastName\":\"Smith\"}",
                "{\"member\":\"John\", " +
                "\"another_member\":\"Smith\"}" 
            };
        }
    }

    private People people;

    public When_I_initialize_People_with_text_that_includes_invalid_data(Context context)
    {
        people = context.SUT;
    }

    [Fact]
    public void It_should_contain_expected_number_of_items()
    {
        people.Count().Should().Be(1);
    }

    [Fact]
    public void It_should_contain_expected_person()
    {
        people.First().ShouldBeEquivalentTo(
            new Person("John", "Smith"));
    }
}

After Fixie

public class When_I_initialize_People_with_text_that_includes_invalid_data
{
    private People people;

    public When_I_initialize_People_with_text_that_includes_invalid_data()
    {
        // Note - I use a custom convention that ensures
        // this arrangement/act is executed once only.
        people = new People {
            "{\"firstName\":\"John\", " +
            "\"lastName\":\"Smith\"}",
            "{\"member\":\"John\", " +
            "\"another_member\":\"Smith\"}"
        };
    }

    [Fact]
    public void It_should_contain_expected_number_of_items()
    {
        people.Count().Should().Be(1);
    }

    [Fact]
    public void It_should_contain_expected_person()
    {
        people.First().ShouldBeEquivalentTo(
            new Person("John", "Smith"));
    }
}

I think its clearer.

There are few problems however:

  • The tests don’t run in parallel which means its slower than xUnit 2.
  • I have to write a custom convention because the one that comes out the box doesn’t support my specification style tests.
  • I decided to use xUnit because I didn’t want to introduce a library that others haven’t heard of or probably even used before – what would they think when I tell them we’re using Fixie now? (I should add that this might just be unique to the place I work. I work with young apprentices that are still finding their feet with testing and their previous experience has been with other xUnit like test frameworks in Java and PHP.)

Fixie or xUnit? What do you think?

The updated code can be found on the Fixie branch here: Specification Test Patterns/Fixie

Specification test patterns

I’m fan of specification style testing. I’ve used mspec on my own projects and have been really happy with it. I would use it at work too, however, most developers I have/are working with have never heard of it let along used it. I would say all these developers have used a xUnit like test framework and if I was to guess which one it would be NUnit. It would be unreasonable of me to force everyone to switch to mspec just because I like it. Also, there is a slight learning curve – when developers already complain that writing tests slow them down, I don’t want them to slow them down further. (There are other reasons too, but I don’t want to go into those.)

So how can we write specification style tests using the tools we already have? Simple, use one test class per test:

public class When_I_initialize_People_with_text
{
    private People people;

    public When_I_initialize_People_with_text()
    {
        people = new People { "{\"firstName\":\"John\", 
                                \"lastName\":\"Smith\"}" };
    }

    [Fact]
    public void It_should_contain_expected_number_of_items()
    {
        people.Count().Should().Be(1);
    }

    [Fact]
    public void It_should_contain_expected_person()
    {
        people.First().ShouldBeEquivalentTo(
            new Person("John", "Smith"));
    }
}

I’m using xUnit 2 in the example above but that’s because I prefer it over NUnit. With xUnit there is just one attribute to remember and the setup/teardown is much simpler.

The test class does one thing – its written on the tin. The assertions, too, are clear. You might not approve of the underscores, but I think its easier to read than using PascalCase.

This pattern is fine for most cases, but what if your setup/teardown parts are slow, for example, seeding a database with some test data. You have to use class fixtures.

public class When_I_initialize_People_with_text_that_includes_invalid_data
    : IClassFixture
{
    public class Context : Context
    {
        public Context()
        {
            SUT = new People { 
                "{\"firstName\":\"John\", " +
                "\"lastName\":\"Smith\"}",
                "{\"member\":\"John\", " +
                "\"another_member\":\"Smith\"}" 
            };
        }
    }

    private People people;

    public When_I_initialize_People_with_text_that_includes_invalid_data(Context context)
    {
        people = context.SUT;
    }

    [Fact]
    public void It_should_contain_expected_number_of_items()
    {
        people.Count().Should().Be(1);
    }

    [Fact]
    public void It_should_contain_expected_person()
    {
        people.First().ShouldBeEquivalentTo(
            new Person("John", "Smith"));
    }
}

Its not quite as readable, but its not bad. (There is an alternative – I’ll save it for a future post.)

Code samples can be found here: Specification Test Patterns

How to find constraint names

Ever tried to drop a DEFAULT CONSTRAINT, how do you find the constraint name – try this:

USE [<database>]

EXEC sp_helpconstraint [<schema>.<table_name>]

GO

I found that little tip here: http://www.mssqltips.com/tip.asp?tip=1425

Useful LINQ to SQL links

I like LINQ to SQL, but I get occasionally caught out when trying something that seems like it should work. It compiles fine, but when you run the code you get: “Static method blah blah blah has no supported translation to SQL.”

This http://msdn.microsoft.com/en-us/library/bb386970.aspx details what methods and types are supported by LINQ to SQL.

Goto http://msdn.microsoft.com/en-us/library/bb386934.aspx for a general reference.