Unit testing your IoC container

I decided to write this post after reading a question on StackOverflow, where the OP was asking for recommendations to simplify his IoC setup code – to make it more readable and also to prevent runtime errors when resolving instances, whenever a change is made.

I feel his pain. Anyone that used and configured an IoC container such as Unity knows how easy it is to break things when you add or change an existing configuration. So, how to detect if things are broken until it’s too late (runtime errors)? Writing tests, obviously.

In this post I’ll show you a quick and simple way to test your dependencies using Unity IoC container.


The scenario – a shopping cart service

Let’s assume a simple scenario – a service that allows users to check the all the items and corresponding prices of his shopping cart. The service uses a logger, a repository to read the information of the cart and a currency service that is used to display the prices in the currency selected by the user:

Source code is the following (methods omitted for brevity):

public interface ILogger
{
}

public class AsyncLogger : ILogger
{
}

public class ConsoleLogger : ILogger
{
}

public class FileLogger : ILogger
{
}

public interface ICurrencyApiClient
{
}

public class CurrencyApiClient : ICurrencyApiClient
{
    private readonly string _apiKey;
    private readonly ILogger _logger;

    public CurrencyApiClient(string apiKey, ILogger logger)
    {
        _apiKey = apiKey ?? throw new ArgumentNullException(nameof(apiKey));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }
}

public interface IRepository
{
}

public class Repository : IRepository
{
    private readonly string _connectionString;

    public Repository(string connectionString)
    {
        _connectionString = connectionString ?? throw new ArgumentNullException(nameof(connectionString));
    }
}

public class ShoppingCartService : IShoppingCartService
{
    private readonly IRepository _repository;
    private readonly ICurrencyApiClient _currencyApiClient;
    private readonly ILogger _logger;

    public ShoppingCartService(IRepository repository, ICurrencyApiClient currencyApiClient, ILogger logger)
    {
        _repository = repository ?? throw new ArgumentNullException(nameof(repository));
        _currencyApiClient = currencyApiClient ?? throw new ArgumentNullException(nameof(currencyApiClient));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }
}

Configuring the dependencies

The first thing to do is to put the IoC code in a class library that can be easily referenced by a test project. You can then add your Bootstrapper class, something like this:

    public class Bootstrapper
    {
        public IUnityContainer Init()
        {
            var container = new UnityContainer();

            // dependencies registration goes here....

            return container;
        }
    }

Please note that the Init() method returns the IoC container – you’ll need it in the unit tests when trying to resolve the instances.

Full source code of the Bootstrapper is the following:

    public class Bootstrapper
    {
        private readonly NameValueCollection _appSettings;
        private readonly ConnectionStringSettingsCollection _connectionStrings;

        public Bootstrapper(
            NameValueCollection appSettings = null,
            ConnectionStringSettingsCollection connectionStrings = null
        )
        {
            _appSettings = appSettings ?? ConfigurationManager.AppSettings;
            _connectionStrings = connectionStrings ?? ConfigurationManager.ConnectionStrings;
        }

        public IUnityContainer Init()
        {
            var container = new UnityContainer();

            // default logger is AsyncLogger
            container.RegisterType();

            // named instances for loggers
            container.RegisterType(nameof(AsyncLogger));
            container.RegisterType(nameof(ConsoleLogger));
            container.RegisterType(nameof(FileLogger));

            container.RegisterType(new InjectionFactory(CreateCurrencyApiClient));
            container.RegisterType(new InjectionFactory(CreateRepository));

            container.RegisterType();

            return container;
        }
    }

Some notes:

  • The constructor takes 2 optional parameters (appSettings and connectionStrings), which can be used for testing purposes. If no values are provided it will use the values from the configuration file.
  • AsyncLogger, ConsoleLogger and FileLogger are registered as named instances
  • ICurrencyApiClient and IRepository are registered using a factory method

Configuring the unit tests

Now it’s time to write the unit tests. Instead of manually adding tests for every single dependency, we can use the Registrations property of IUnityContainer to get the metadata of all registered dependencies:

Writing the tests (using NUnit and Fluent Assertions):

 
    [TestFixture]
    public class BootstrapperTests
    {
        private static IUnityContainer Container => new Bootstrapper().Init();

        private static IEnumerable UnityRegistrations
        {
            get
            {
                var registrations = Container.Registrations
                                             .Where(x => x.RegisteredType != typeof(IUnityContainer))
                                             .Select(x => new TestCaseData(x.RegisteredType, x.Name));

                return registrations;
            }
        }

        [Test]
        [TestCaseSource(nameof(UnityRegistrations))]
        public void GivenATypeAndName_WhenResolvingInstance_InstanceShouldNotBeNull(Type registeredType, string instanceName)
        {
            // arrange/act
            object instance = Container.Resolve(registeredType, instanceName);

            // assert
            using (new AssertionScope())
            {
                instance.Should().BeAssignableTo(registeredType);
                instance.Should().NotBeNull();
            }
        }
    }

It’s just as simple as that. Given the registered type and the instance name of the dependencies, I can try to resolve them. If the instance is null or an exception is thrown the test will fail, which means that there is something wrong with our Bootstrapper. Also, I check if the returned instance has the expected type.

Running the code using Reshaper:

Some tests failed because I forgot to add a configuration file with the settings used by both the CurrencyApiClient and Repository. Test for IShoppingCartService fails as well because it uses both dependencies.

Fixing the code and running the tests:

All good now. As you can see, there is a test for every single type/instance name.

Final thoughts

You should add as many unit tests as possible to your code – IoC setup is no exception. Also, these tests do not exclude the usage of other type of tests such as integration or smoke tests.

My article is a good starting point, but this might not be enough. For example, if you have ASP.NET MVC or ASP.NET Web API applications, you should test your DependencyResolver in order to ensure that all controllers are being instantiated correctly (i.e. without throwing exceptions).

Consider also running these tests for every single environment – each environment has its own configuration, so better be safe than sorry 😉

Happy coding!

Advertisements

Using Dictionaries to replace long if or switch statements

Imagine the following scenario – you have created some validators for your models: Foo, Bar and Xyz.

    public interface IValidator
    {
        bool Validate(object model);
    }

    // Validator for Foo class
    public class FooValidator : IValidator
    {
        public bool Validate(object model)
        {
            // ...
        }
    }

    // Validator for Bar class
    public class BarValidator : IValidator
    {
        public bool Validate(object model)
        {
            // ...
        }
    }

    // Validator for Xyz class
    public class XyzValidator : IValidator
    {
        public bool Validate(object model)
        {
            // ...
        }
    }

You decide to create a factory class for the validators to prevent users from creating instances directly using the new keyword. For example, this code would create a validator for Foo:

    var model = new Foo();
    var validatorFactory = new ValidatorFactory();
    IValidator validator = validatorFactory.CreateValidatorFor<Foo>();

    if (validator.Validate(model))
    {
        // ...
    }

Implementation of the factory:

    using System;

    public class ValidatorFactory
    {
        public IValidator CreateValidatorFor<T>()
        {
            Type modelType = typeof (T);
            IValidator validator = CreateValidatorFor(modelType);

            return validator;
        }

        public IValidator CreateValidatorFor(Type modelType)
        {
            if (modelType == null)
            {
                throw new ArgumentNullException("modelType");
            }

            if(modelType == typeof(Foo))
            {
                return new FooValidator();
            }
            else if(modelType == typeof(Bar))
            {
                return new BarValidator();
            }
            else if(modelType == typeof(Xyz))
            {
                return new XyzValidator();
            }

            string errorMessage = string.Concat("Could not find validator for type ", modelType.FullName);
            throw new ArgumentException("modelType", errorMessage);
        }
    }

As you can see, for each model you have an if statement. This works fine if you only need to create 2 or 3 validators but if you need more your code will get bigger and bigger and will be harder to read/maintain. The same applies to switch statements.

The first step to solve this problem is to create a Dictionary to store the validators. The key of the Dictionary will be the type of the model and the value will be a delegate that creates an instance of the validator for that model:

	var validators = new Dictionary<Type, Func<IValidator>>
	{
		{ typeof(Foo), () => new FooValidator() },
		{ typeof(Bar), () => new BarValidator() },
		{ typeof(Xyz), () => new XyzValidator() }
	};

Changing the implementation of the factory to use the dictionary:

    public class ValidatorFactory : IValidatorFactory
    {
        private static Dictionary<Type, Func<IValidator>> _validators =
			new Dictionary<Type, Func<IValidator>> {
            { typeof(Foo), () => new FooValidator() },
            { typeof(Bar), () => new BarValidator() },
            { typeof(Xyz), () => new XyzValidator() }
        };

        public IValidator CreateValidatorFor<T>()
        {
            Type modelType = typeof (T);
            IValidator validator = CreateValidatorFor(modelType);

            return validator;
        }

        public IValidator CreateValidatorFor(Type modelType)
        {
            if (modelType == null)
            {
                throw new ArgumentNullException("modelType");
            }

            Func<IValidator> validatorFunc;

            if (_validators.TryGetValue(modelType, out validatorFunc))
            {
                IValidator validator = validatorFunc();

                return validator;
            }

            string errorMessage = string.Concat("Could not find validator for type ", modelType.FullName);
            throw new ArgumentException("modelType", errorMessage);
        }
    }

That’s it, code looks much nicer now! To configure a new validator just add a new key/value pair to the _validators Dictionary.

Finally, testing the code using NUnit:

	// arrange
	var factory = new ValidatorFactory();

	// act
	IValidator validator = factory.CreateValidatorFor<Foo>();

	// assert
	Assert.That(validator, Is.TypeOf<FooValidator>());

Implementing a basic IoC container using C#

Implementing a basic IoC container using C#, step by step.

Table of contents

  • References
  • Downloads
  • Continue reading

    Entity Framework and T4: Generate Specification Objects for your entities

    Learn how to use Specification Pattern and how to generate Specification Objects for your Entity Framework entities using T4 templates.

    Table of contents

    Specification Pattern Overview

    According to Martin Fowler and Eric Evans, a specification define a set of conditions that a candidate object must fulfill in order to meet the specification. Specifications can be used for:

    • Selection: When you need to select a set of objects based on some criteria
    • Validation: when you need to check that only suitable objects are used for a certain purpose

    The Specification Pattern can be represented like this in .NET (using generics):

    public interface ISpecification<T> where T : class
    {
        Expression<Func<T, bool>> GetExpression();
        bool IsSatisfiedBy(T entity);
    }
    

    We can also create Composite Specifications by combining other specifications – this allow us to reuse existing specifications to create more complex ones.

    Using Specification Pattern

    I’m using the MVC Music Store database, this is the model:

    Music Store Model
    And now some examples. I will assume that you have a repository like this (I’m using this implementation):

    public IQueryable All<T>(Expression<Func<bool, T>> expression) where T : class
    

    A generic Specification class

    public class Specification<T> : ISpecification<T> where T : class
    {
        private Expression<Func<T, bool>> expression;
    
        public Expression<Func<T, bool>> GetExpression()
        {
            return expression;
        }
    
        public Specification(Expression<Func<T, bool>> expression)
        {
            this.expression = expression;
        }
    
        public bool IsSatisfiedBy(T entity)
        {
            var query = (new[] { entity }).AsQueryable();
    
            return query.Any(this.expression);
        }
    }
    

    Creating specifications

    Using the generic class to create specifications:

    • One specification for jazz albums
    • One specification for cheap albums (price between 1 and 10)
    public static ISpecification<Album> JazzAlbumSpecification
    {
    	get
    	{
    		return new Specification<Album>(
    			x => x.Genre.Name == "Jazz"
    		);
    	}
    }
    
    public static ISpecification<Album> CheapAlbumSpecification
    {
    	get
    	{
    		return new Specification<Album>(
    			x => x.Price >= 1 && x.Price <= 10
    		);
    	}
    }
    

    Selecting objects

    var albums = from x in repository.All<Album>(JazzAlbumSpecification.GetExpression())
                 select x;
    

    Performing validation

    Album metalAlbum = GetMetalAlbum();
    Album jazzAlbum = GetJazzAlbum();
    
    bool isJazzAlbum = JazzAlbumSpecification.IsSatisfiedBy(metalAlbum); 
    isJazzAlbum = JazzAlbumSpecification.IsSatisfiedBy(jazzAlbum);
    

    Composing specifications

    Existing specifications can be combined to form more complex ones. Using these extension methods it’s easy to create composite specifications (see this article to understand how to combine lambda expressions):

    public static ISpecification<T> And<T>(this ISpecification<T> first, ISpecification<T> second) where T : class
    {
        return new Specification<T>(
            first.GetExpression()
            .And(second.GetExpression())
        );
    }
    
    public static ISpecification<T> Or<T>(this ISpecification<T> first, ISpecification<T> second) where T : class
    {
    	return new Specification<T>(
            first.GetExpression()
            .Or(second.GetExpression())
        );
    }
    

    The specifications defined above can now be combined to compose a new specification like this:

    ISpecification<Album> cheapJazzAlbumSpecification = JazzAlbumSpecification.And(CheapAlbumSpecification);
    
    // using the specification to select all cheap jazz albums
    var cheapJazzAlbums = from x in repository.All<Album>(cheapJazzAlbumSpecification.GetExpression())
                          select x;
    

    Using T4 to generate Specification Objects

    T4 is a code generator built right into Visual Studio. You can generate any text file using T4 templates: C#, javascript, HTML, XML and many others. If you’ve never heard about it, this is a good place to start:

    T4 (Text Template Transformation Toolkit) Code Generation – Best Kept Visual Studio Secret

    I’ve created a T4 template that generates automatically all the Specification Objects, one for each entity in our model. All the generated objects have all the public properties of their respective entities, including association properties. All objects were marked with the [Serializable] attribute, so you can easily serialize it if you need.

    In a previous article I’ve created query objects for Entity Framework, I’m generating exactly the same properties in this template. You can see a complete description of the generated properties here.

    This is the generated object model:


    The previous specifications can now be written like this:

    public static ISpecification<Album> JazzAlbumSpecification
    {
        get
        {
            return new AlbumSpecification() {
                Genre = new GenreSpecification() { Name = "Jazz" }
            };
        }
    }
    
    public static ISpecification<Album> CheapAlbumSpecification
    {
        get
        {
            return new AlbumSpecification() {
                PriceFrom = 1,
                PriceTo = 10
            };
        }
    }
    

    Configuration

    In the demo solution double-click ModelSpecification.tt and change the following lines, according to your needs:

    string inputFile = @"Model.edmx";
    string namespaceName = @"MusicStore.Model";
    string filenameSuffix = "Specification.gen.cs";
    

    When you save the template file or you rebuild the project the code will be regenerated. If you don’t want to generate the code, remove the value of the Custom Tool property in the property browser of the template file (by default the value is TextTemplatingFileGenerator).

    References

    [1] Specification Pattern

    [2] Specification (Martin Fowler/Eric Evans)

    [3] T4 (Text Template Transformation Toolkit) Code Generation – Best Kept Visual Studio Secret

    [4] LINQ to Entities: Combining Predicates

    [5] Implementing ISession in EF4

    Downloads

    Download the demo project: MusicStore-T4-Specification.rar

    
    

    Entity Framework and T4: Generate Query Objects on the fly, part 1

    Generate Query Objects on the fly for your Entity Framework entities using T4 templates. Don’t worry about LINQ, let the objects do all the work for you.

    Table of contents

  • Configuration
  • References
  • Downloads
  • I’ve read some stuff about T4 templates in the last 2-3 years, but only recently I decided to give it a try. My first attempt was to generate Query Objects for Entity Framework, that’s what I’ll talk about in this article – what’s their purpose and how to use them.

    In part 2 I’ll create a demo ASP.NET MVC application that uses query objects created with this template. I already have another T4 template that creates javascript objects for my entities, and I’m developing a custom ASP.NET view template for those objects.

    Many thanks to Colin Meek [4], his work has really helpful.

    What is a Query Object?

    A Query Object is an object that represents a database query [1]:

    A Query Object is an interpreter [Gang of Four], that is, a structure of objects that can form itself into a SQL query. You can create this query by referring to classes and fields rather than tables and columns. In this way those who write the queries can do so independently of the database schema and changes to the schema can be localized in a single place.

    Assuming that you have a repository like this (I’m using this implementation):

    public IQueryable All<T>(Expression<Func<bool, T>> expression) where T : class
    

    Instead of:

    var albuns = from x in repository.All<Album>()
                     where x.Artist.Name == "Metallica"
                     && x.Genre.Name.Contains("Metal")
                     && x.Price >= 5 && x.Price
                     select x;
    

    You can do this way:

    var search = new AlbumSearch();
    search.PriceFrom = 5;
    search.PriceTo = 10;
    search.Artist = new ArtistSearch(){ Name = "Metallica" };
    search.Genre = new GenreSearch(){ NameContains = "Metal" };
    
    var albuns = from x in repository.All<Album>(search.GetExpression())
                      select x;
    

    Continue reading

    Improve your UI code with Strategy Pattern

    This article is intended to provide a brief introduction to the Strategy Design Pattern, and how can help us to improve our User Interface code.

    The scenario – A simple blogging application

    Blogging application - showing actions by role

    You have a blog application and you want to limit user actions based on their roles.
    You have the following roles:

    • User
    • Writer
    • Editor

    and the following actions:

    • New Post – Creates a new blog post
    • Edit Post – Edits an existing blog post
    • Submit Post – Submits a post for approval
    • Reject Post – Rejects a previously submitted blog post
    • Publish Post – Publishes a previously submitted blog post

    The table below shows the actions per role type

    Actions

    User

    Writer

    Editor

    New post

    x

    Edit post

    x

    Submit post

    x

    Reject post

    x

    Publish post

    x

    Role type is represented by an enumeration:

    public enum RoleType
    {
        User,
        Writer,
        Editor
    }
    

    What’s the best solution for our problem?

    Continue reading