antony_scott

If you find yourself getting this error message when you change your URL in the test client between you different APIs …

The HttpClient instance already started one or more requests. Properties can only be modified before sending the first request.

You have fallen foul of a little WCF Web Api gotcha. Message handlers need to be created each time they are required. I was using Castle Windsor to handle the lifetime of my message handlers

    public class MessageHandlerInstaller : IWindsorInstaller
    {
        public void Install(IWindsorContainer container, IConfigurationStore store)
        {
            var path = Assembly.GetExecutingAssembly().GetDirectoryName();
            var filter = new AssemblyFilter(path, "ByBox*.dll");

            container.Register(
                AllTypes
                    .FromAssemblyInDirectory(filter)
                    .Where(t => t.IsSubclassOf(typeof (DelegatingHandler)))
                    .Configure(c => c.LifeStyle.Custom(InstallerContext.LifestyleManager))
                );
        }
    }

So, I’m using my InstallerContext’s lifestyle, but what I actually needed was this …

                    .Configure(c => c.LifeStyle.Transient)

I found this in a discussion on the wcf codeplex site

I have just recently discovered the [TestCase] attribute of NUnit. With careful use it can drastically reduce the number of test methods you need to write. For my needs on a recent project I wanted to check field values which were being pulled from my database. What I’ve come up with is a simple extension to the NUnit Assert class which allows me to write test code such as …

[TestCase(0, "Forename", "Antony")]
[TestCase(0, "Surname", "Scott")]
[TestCase(0, "TwitterUserName", "antony_scott")]
public void ExampleTest(int index, string fieldname, object expectedValue)
{
    var result = GetPersonDetails();
    var list = result.ToList();
    Assert.IsFieldEqual(list.ElementAt(index), fieldname, expectedValue);
}

This gives me a very compact and easy to understand test with great visibility of any fields which are being pulled from the database correctly. All this is nothing new, as I’ve blogged about it previously here.

What I’ve added is the ability to dig into a structure like so …

[TestCase(0, "Forename", "Antony")]
[TestCase(0, "Surname", "Scott")]
[TestCase(0, "Twitter.UserName", "antony_scott")]
public void ExampleTest(int index, string fieldname, object expectedValue)
{
    var result = GetPersonDetails();
    var list = result.ToList();
    Assert.IsFieldEqual(list.ElementAt(index), fieldname, expectedValue);
}

In case you can’t see any difference, it’s the “dot” in the 3rd test case.

Here is the “extension” of the Assert class which makes it possible …

    public class Assert : NUnit.Framework.Assert
    {
        public static void IsFieldEqual(object obj, string propertyName, object expectedValue)
        {
            var type = obj.GetType();

            var dotIndex = propertyName.IndexOf('.');
            if (dotIndex != -1)
            {
                var innerObjName = propertyName.Substring(0, dotIndex);
                var innerPropName = propertyName.Substring(dotIndex + 1);
                var innerProp = type.GetProperty(innerObjName);
                var innerObj = innerProp.GetValue(obj, null);
                IsFieldEqual(innerObj, innerPropName, expectedValue);
            }
            else
            {
                var prop = type.GetProperty(propertyName);
                var actualValue = prop.GetValue(obj, null);
                AreEqual(expectedValue, actualValue);
            }
        }
    }

Actually generating the schema is pretty simple …

using Newtonsoft.Json.Schema;

var jsonSchemaGenerator = new JsonSchemaGenerator();
var myType = typeof(MyClass);
var schema = jsonSchemaGenerator.Generate(myType);
schema.Title = myType.Name; // this doesn't seem to get done within the generator

then write it to a file …

var writer = new StringWriter();
var jsonTextWriter = new JsonTextWriter(writer);
schema.WriteTo(jsonTextWriter);
var prettyString = JsonPrettifier.Prettify(writer.ToString());
var fileWriter = new StreamWriter("MySchema.txt");
fileWriter.WriteLine(schema.Title);
fileWriter.WriteLine(new string('-', schema.Title.Length));
fileWriter.WriteLine(prettyString);
fileWrite.Close();

What took me a while to figure out was that MyClass needs to be decorated with specific attributes in order for the schema to be correctly generated.

public class MyClass
{
    [JsonProperty(Required = Required.Always)]
    public string Forename { get; set; }

    [JsonProperty(Required = Required.Always)]
    public string Surname { get; set; }

    [JsonProperty(Required = Required.Always)]
    public string EmailAddress { get; set; }

    [JsonProperty(Required = Required.AllowNull)]
    public string MobilePhoneNumber { get; set; }
}

So, the JsonProperty attribute is your friend here! I took my a while to figure out, including some time stepping through the Json.NET source code in the debugger.

I recently wrote about using reflection to check for null values in conjunction with the TestCase attribute. I’ve just taken this a step further by creating a derived Assert class …

public class Assert : NUnit.Framework.Assert
{
    public static void IsFieldEqual(object obj, string propertyName, object expectedValue)
    {
        var type = obj.GetType();
        var prop = type.GetProperty(propertyName);
        var actualValue = prop.GetValue(obj, null);
        AreEqual(expectedValue, actualValue);
    }
}

This allows me to write tests to check the value of each field in a result object and have the assert fail on the specific field, it also doesn’t stop the other field being tested. So, using the TestCase attribute I can write tests such as this …

[TestCase("Forename", "Antony")]
[TestCase("Surname", "Scott")]
public void example_test(string fieldname, object expectedValue)
{
    // Arrange
    Context.AddPerson(new Person { ID = 1, Forename = "Antony", Surname = "Scott" });

    // Act
    var result = Service.GetPerson(1);

    // Assert
    Assert.IsFieldEqual(result, fieldname, expectedValue);
}

Obviously this is an over-simplified example. But, the idea is that I can now have a complex object being loaded up by an integration test into my database. I then use a Service of some kind (what I’m testing) to query my database and I can then make sure all the correct details have been retrieved from the database.

I’ve been working on a RESTful api recently using WCF Web Api (Preview 6). It’s like a breath of fresh air to work on something so uncluttered, I’ve come from working on a complex, multi-technology, web site. Working with a RESTful api is just so simple, but it presents its own challenges which I am overcoming one by one. One such challenge is validating the resources coming in via a POST method. I found a very useful answer on stack overflow which got me some of the way there. I spent some time refining it a bit and eventually came up with this …

using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using System.Net.Http;
using ByBox.WebApi.HttpResponseMessages;
using Microsoft.ApplicationServer.Http.Dispatcher;

namespace WhateverYouWant
{
    public class ValidationHandler<TResource> : HttpOperationHandler<TResource, HttpRequestMessage, HttpRequestMessage>
    {
        public ValidationHandler() : base("response") { }

        protected override HttpRequestMessage OnHandle(TResource model, HttpRequestMessage requestMessage)
        {
            var results = new List<ValidationResult>();
            var context = new ValidationContext(model, null, null);
            Validator.TryValidateObject(model, context, results, true);

            if (results.Count == 0)
            {
                return requestMessage;
            }

            var errorMessages = results.Select(x => x.ErrorMessage).ToArray();

            var mediaType = requestMessage.Headers.Accept.FirstOrDefault();
            var response = new RestValidationFailure(errorMessages);
            if (mediaType != null)
            {
                response.Content = new ObjectContent(typeof(string[]), errorMessages, mediaType);
            }
            throw new HttpResponseException(response);
        }
    }
}

What I added to the answer on stack overflow was the ability to return a list of error messages in both the headers and the body of the response. The list of errors in the body are sent in the format the browser will “accept”. This helps keep everything simple on the client side. I have only checked if it works for xml and json. For the sake of completeness I have included a version of my RestValidationFailure class.

using System.Net.Http;

namespace WhateverYouWant
{
    public class RestValidationFailure : HttpResponseMessage
    {
        public RestValidationFailure(string[] errorMessages)
        {
            StatusCode = HttpStatusCode.BadRequest;
            foreach (var errorMessage in errorMessages)
            {
                Headers.Add("X-Validation-Error", errorMessage);
            }
        }
    }
}

I’ve got used to treating everything as a service in recent years, since I started using Castle Windsor. I only ever instantiate my own classes in unit/integration tests these days. My latest project has been to write a RESTful service using preview 6 of the WCF Web Api framework. (Also available via nuget, just add the WebApi.All package and you’re all set). It’s actually quite simple to make the web api use castle windsor.

From my Application_Start() method I call a ConfigureApi(RouteCollection routes) method. This create the config object and then sets up any routes …

    private static void ConfigureApi(RouteCollection routes)
    {
        Container = CreateContainer();

        var config = new MyApiConfiguration(Container);
        routes.SetDefaultHttpConfiguration(config);

        routes.MapServiceRoute<MyApi>("myresource");
    }

I then set up CreateInstance, ErrorHandlers, and MessageHandlerFactory with anonymous methods which simply call the relevant Resolve methods on my container.

public class MyApiConfiguration : WebApiConfiguration
{
    public MyApiConfiguration(IWindsorContainer container)
    {
        EnableTestClient = GetSetting("TestClient");
        IncludeExceptionDetail = GetSetting("IncludeExceptionDetail");

        CreateInstance = ((serviceType, context, request) => container.Resolve(serviceType));
        ErrorHandlers = (handlers, endpoint, description) => handlers.Add(container.Resolve<GlobalErrorHandler>());
        MessageHandlerFactory = () => container.ResolveAll<DelegatingHandler>();

        this.ValidateAllResourceTypes();
    }

    private static bool GetSetting(string settingName)
    {
        bool flag;
        bool.TryParse(ConfigurationManager.AppSettings[settingName] ?? "false", out flag);
        return flag;
    }
}

And that’s all there is to it. Simple really.

ValidateAllResourceTypes is something I will blog about another time. It uses reflection to register all resource types for validation via data annotations.

I’ve been writing a lot more integration tests for my recent projects in which I’ve made use of Entity Framework. I’m purely using code first as I never really got along with the whole draggy droppy designer affair. I came to realise recently that I was writing an awful lot of code to mock out my data layer (using Moq). But all I was really doing was making sure that my Linq queries pulled back the correct data. Even after having gone to all the effort I was still getting problems with my code when it got to see a database for the first time. Usually to do with me doing things which cannot be converted in to T-SQL. So I’ve decided to ditch unit testing and mocking for any data layer stuff and go totally over the integration testing. Making the move to entity framework code first has made that very simple. First off I create a couple of “self-creating” properties for my Context and Repository.

    private DomainContext _context;
    protected DomainContext Context
    {
        get { return _context ?? (_context = new DomainContext(ConfigurationManager.ConnectionStrings["ByBox"].ConnectionString)); }
        private set { _context = value; }
    }

    private ConsumerRepository _repository;
    private ConsumerRepository Repository
    {
        get { return _repository ?? (_repository = new ConsumerRepository(Context)); }
        set { _repository = value; }
    }

Then I have some straight forward setup/teardown code. All this usually ends up in a base class of some kind which I re-use in all my different test source files.

    [TestFixtureSetUp]
    public virtual void TestFixtureSetUp()
    {
        try
        {
            var seed = new DomainDataSeed();
            Database.SetInitializer(seed);
            Context.Database.Initialize(true);
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex);
            throw;
        }
    }

    [TestFixtureTearDown]
    public virtual void TestFixtureTearDown()
    {
        Repository.Dispose();
        Repository = null;
        Context.Dispose();
        Context = null;
    }

Another useful thing to do is to be able to reset the database to a know state. You may have noticed these 3 lines above …

            var seed = new DomainDataSeed();
            Database.SetInitializer(seed);
            Context.Database.Initialize(true);

What these do is use a data seed class to initialise the database. By way of example, here is a snippet from my seed class …

    public class DomainDataSeed : DropCreateDatabaseAlways<DomainContext>
    {
        protected override void Seed(DomainContext context)
        {
            AddWebServiceUsers(context);
            AddUserAccounts(context);

            context.SaveChanges();
        }

        private void AddWebServiceUsers(DomainContext context)
        {
            context.Database.ExecuteSqlCommand("CREATE TABLE [web_service_user] ( ... )");
            context.Database.ExecuteSqlCommand("CREATE TABLE [web_service_user_attribute] ( ... )");
            context.Database.ExecuteSqlCommand("INSERT INTO [web_service_user] ([username], [password]) values({0}, {1})", Username, Password);
        }
        private static void AddUserAccounts(DomainContext context)
        {
            context.UserAccounts.Add(
                new UserAccount
                    {
                        ...
                    });
        }
    }

If I wanted to I could put that code into the [SetUp] method rather than the [TestFixtureSetUp] method. Or, as I have done recently in a ResetDatabase() method, which I call from the [TestFixtureSetUp] and select tests as required. This particular seed class drops and re-creates the database every time it is called, thanks to this – DropCreateDatabaseAlways<DomainContext>. There are other options available, including only dropping and re-creating the database (and seeding it) when the model changes.

I recently had a need to write some unit (actually integration) tests which would check how I handled field being null. Without using the [TestCase] attribute of NUnit my tests would have looked something like this …

    public void validation_failure_identifier_null_400_expected()
    {
        // Arrange
        var resource = CreateCompleteResource();
        resource.Identifier = null;
        var jsonString = JsonPrettifier.Prettify(resource);

        // Act
        var result = Service.Post(jsonString);

        // Assert
        result.Message.CheckForValidationError("Identifier");
    }

    public void validation_failure_forename_null_400_expected()
    {
        // Arrange
        var resource = CreateCompleteResource();
        resource.Forename = null;
        var jsonString = JsonPrettifier.Prettify(resource);

        // Act
        var result = Service.Post(jsonString);

        // Assert
        result.Message.CheckForValidationError("Forename");
    }

… and so on.

BUT, by using a little reflection in conjunction with the [TestCase] attribute of NUnit, I can do this …

    private string GenerateJsonAndSetFieldTo(string fieldName, string value)
    {
        var resource = CreateCompleteResource();
        var type = resource.GetType();
        var prop = type.GetProperty(fieldName);
        prop.SetValue(resource, value, new object[0]);
        var jsonString = JsonPrettifier.Prettify(resource);
        return jsonString;
    }

    [TestCase("Identifier")]
    [TestCase("Forename")]
    public void validation_failure_400_expected(string fieldName)
    {
        // Arrange
        var jsonString = GenerateJsonAndSetFieldTo(fieldName, null);

        // Act
        var result = Service.Post(jsonString);

        // Assert
        result.Message.CheckForValidationError(fieldName);
    }

Obviously I have more TestCase’s than shown here, I didn’t want to bore you all with them! Less tests to maintain, easier to add null checking for other fields and it also looks neater in my test runner of choice.

I recently wrote about how to Automatically Add Framework Config Classes to the Model Builder. Since writing that post I have come across a situation where I was writing the exact same model class in a different application. That just didn’t smell right to me, since the other applications data access layer had been packaged up by nuget I could simply add a reference to it. That’s all well and good, but I didn’t want to have to go to any special effort to add the model configuration classes I needed to my modelbuilder. So, I’ve created a fairly simple (although it’s taken me a while to get it working how I want it) base class from which I can derive my context classes.

using System;
using System.Collections.Generic;
using System.ComponentModel.Composition.Hosting;
using System.Data.Entity;
using System.Data.Entity.ModelConfiguration;
using System.IO;
using System.Linq;
using System.Reflection;

namespace Base.EntityFramework
{
    public abstract class BaseDbContext : DbContext
    {
        protected BaseDbContext() { }
        protected BaseDbContext(string connectionString) : base(connectionString) { }

        private IEnumerable<Type> GetTypes()
        {
            var type = typeof(EntityTypeConfiguration<>);
            return GetType()
                .GetProperties(BindingFlags.Instance | BindingFlags.Public)
                .Where(p => p.PropertyType.IsGenericType &&
                            p.PropertyType.GetGenericTypeDefinition() == typeof(IDbSet<>))
                .Select(p => type.MakeGenericType(p.PropertyType.GetGenericArguments().First()))
                .ToArray();
        }

        private static void LoadAllEntityConfigurationsFromAllAssemblies(DbModelBuilder modelBuilder, IEnumerable<Type> types, string assemblyFilter, IEnumerable<string> namePartFilters)
        {
            var path = Path.GetDirectoryName((new Uri(Assembly.GetExecutingAssembly().CodeBase)).AbsolutePath);
            new DirectoryCatalog(path, assemblyFilter)
                .LoadedFiles
                .Where(x =>
                {
                    var fileNameWithoutExtension = Path.GetFileNameWithoutExtension(x.ToLower());
                    if (fileNameWithoutExtension != null)
                    {
                        var parts = fileNameWithoutExtension.Split(".".ToCharArray());
                        return parts.Any(part => namePartFilters.Any(namePartFilter => part == namePartFilter.ToLower()));
                    }
                    return false;
                })
                .Select(Assembly.LoadFrom)
                .ToList()
                .ForEach(assembly => assembly.GetTypes()
                                         .Where(t => types.Contains(t.BaseType))
                                         .Select(Activator.CreateInstance)
                                         .ToList<dynamic>()
                                         .ForEach(instance => modelBuilder.Configurations.Add(instance)));
        }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            base.OnModelCreating(modelBuilder);

            var typesToLoad = GetTypes();
            LoadAllEntityConfigurationsFromAllAssemblies(modelBuilder, typesToLoad, "*.dll", new[] { "Data", "Domain" });
        }

    }
}

and in english ….

1. Discover which classes for which I need to find and load the relevant EntityTypeConfiguration<> class. This is done with a little bit of reflection in the GetTypes() method.
2. Use MEF to find the assemblies the config classes might be in. In this case it’s all of them (*.dll), but that could be changed to whatever is best for your situation.
3. Use the namePartFilters to narrow down the list of assemblies further. In this case I’m looking for anything with “Data” or “Domain” in the filename (after it’s been split by periods).
4. Load each assembly.
5. Load any generic EntityTypeConfiguration types for the model classes used within my context class (the one which is derived from this base class).
6. Instantiate each config class.
7. Add it to the modelBuilder’s configurations.

Since this is a base class I can get this behaviour whenever I derive from it ….

    public class DomainContext : BaseDbContext, IDomainContext
    {
        public IDbSet<Employee> Employees { get; set; }

        public DomainContext() { }
        public DomainContext(string connectionString) : base(connectionString) { }

        IQueryable<Employee> IDomainContext.Employees { get { return Employees; } }
    }

What this allows me to do is use models from any assembly I am referencing in my application and just add it to my Context. Any configuration class for it will then be automatically added to the model builder.

I’ve just completed a bit of TDD. Proper TDD, I wrote the code to pass the tests and wrote the tests first. Anyway, one thing I needed control over was the concept of “now”. This particular method I was testing/writing deals with DateTime objects.

I needed a way of defining, on a per test basis, what “now” is. There were two steps to achieving this. Firstly, I needed to use an interface to get “now”.

    public interface IDateTimeProvider
    {
        DateTime Now { get; }
    }

So, rather than using DateTime.Now, I use DateTimeProvider.Now.

The second step is creating the mock IDateTimeProvider and using the lazy loading feature of Moq. In this particular case I am using Moq and a test base class …

    [TestFixture]
    public abstract class BaseTest
    {
        private Mock<IDateTimeProvider> _mockDateTimeProvider;
        protected IDateTimeProvider DateTimeProvider { get { return _mockDateTimeProvider.Object; } }

        [SetUp]
        public void Setup()
        {
            _mockDateTimeProvider = new Mock<IDateTimeProvider>();
            Now = DateTime.MinValue;
            _mockDateTimeProvider.Setup(x => x.Now).Returns(() =>
                                                               {
                                                                   if (Now == DateTime.MinValue)
                                                                   {
                                                                       throw new Exception("'Now' property must be set in each [Test] method");
                                                                   }
                                                                   return Now;
                                                               });
        }

        protected DateTime Now { private get; set; }
    }

So, I have a DateTime property, which is evaluated whenever the IDateTimeProvider.Now method is called. I added a little check to make sure the Now property is set in each test. That, coupled with setting Now to DateTime.MinValue means any test which doesn’t set the value will get a helpful message in your chosen test runner.

The crucial part of that code and what makes it really useful is the lazy evaluation, which is done like so …

                                                            () =>
                                                               {
                                                                   if (Now == DateTime.MinValue)
                                                                   {
                                                                       throw new Exception("'Now' property must be set in each [Test] method");
                                                                   }
                                                                   return Now;
                                                               }

I’ve also made the Now and _mockDateTimeProvider private so they cannot be used, forcing the use of the DateTimeProvider.

Here is an example test …

        [Test]
        public void ExampleTest()
        {
            Now = DateTime.Parse("30 Nov 2011 15:00");

            // Arrange

            // Act
            var result = DateTimeProvider.Now;

            // Assert
            Assert.That(result, Is.EqualTo(DateTime.Parse("30 Nov 2011 15:00")));
        }

I’ve explicitly defined the dates in my asserts so it’s a little more obvious what is going on. I’ve also used DateTime.Parse as it’s easier to read. I’ve put the assignment of the Now property before the Arrange section as it’s really a pre-arrange step.

It’s not totally necessary to require Now to be configured explicitly for each test, but I think it makes things a little easier to read for developers coming to this code fresh. It would be possible to have a default value for “Now” but that isn’t very discoverable.