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

Fluent Assertions first look

I always loved Fluent Interfaces – when done properly they can make an API or library easier to use and understand. I’ve heard of Fluent Assertions before, but I confess I never gave it much attention. I usually use NUnit as my unit testing framework and I just though their API was good enough, and to be honest I didn’t want to waste much time learning yet another library. Just out of curiosity, I decided to take a look into their website today to take a look and try to understand what was the motivation behind Fluent Assertions (emphasis is mine):

Nothing is more annoying than a unit test that fails without clearly explaining why. More than often, you need to set a breakpoint and start up the debugger to be able to figure out what went wrong. (…) That’s why we designed Fluent Assertions to help you in this area. Not only by using clearly named assertion methods, but also by making sure the failure message provides as much information as possible.

I completely agree, sometimes you’re just wasting too much time trying to figure out what went wrong. I have to admit that some of the assertion messages provided by NUnit are not great, so I decided to run some tests and compare the messages between these two libraries.

Continue reading

The Bug Cap

I’ve just watched the Agile at Microsoft video, that shows how the Visual Studio Team Services (VSTS) team at Microsoft adopted an Agile mindset and culture. The whole video is interesting but there was one item in particular that caught my eye, which is named the Bug Cap.

The Bug Cap is a simple strategy to keep the bug count low, in order to preserve the software quality. In other words, if your bug count exceeds your bug cap you stop working on new features until you’re back under the cap.

This is the formula suggested by the VSTS Team to calculate the bug cap:

For example, having 5 engineers in one team the bug cap would be:

5 X 5 = 25

Let’s suppose that the bug count at some stage is 30 – this means that the team should stop working on new features until the bug count is less than 25.

This is a very simplistic rule but I guess this is a good starting point in order to limit the number of bugs per sprint and avoid chaos. I guess you can try it with different formulas as well, such as multiplying per 3 or 4 – whatever works for you 🙂

You can watch the whole video here (the bug cap topic starts around 00:29:01):

 

We don’t have time for unit tests

This is probably one of the biggest bullsh*ts people usually tell in the world of software development:

unit-tests1

I’ve heard it many times before, and I bet you’ve heard it too. I was unfortunate enough to work for companies where PMs and other people had this mentality, even giving the impression that unit tests were a waste of time. “Just do it quick and dirty” – this was a very common sentence in one of the last companies I worked for.

A lot has been written about unit tests in the last 15 or 20 years, and the advantages should be obvious by now – you can refactor your code with confidence without the fear of breaking existing functionality, you can run unit tests as part of an automated build, and so on.

But there are disadvantages as well – you do need to spend some time to write the test and debug the piece of functionality you’re testing, as obvious. This is usually the excuse given for NOT writing unit tests. But the truth is that we need to test the functionality somehow – it’s not acceptable to write a piece of code without testing it, right? You simply have to test your code, one way or another – even if you don’t use unit tests.

That leaves me with another question – from a development perspective, do you think that the alternatives ways to test your code are faster than writing a unit test? I don’t think so. I still believe that unit testing is the fastest way to do it, if you have a decent enough experience with it (you don’t need to be an expert, though). Let’s analyse the following scenario below.

The scenario – discount calculator

Imagine that you are working on an e-commerce website – the UI is an ASP.NET website that uses a REST API (ASP.NET Web API), where all the business logic is. You need to implement a discount calculator in the API, based on the customer type:

  • Platinum (20% discount)
  • Gold (10% discount)
  • Silver (5% discount)
  • Standard (no discount)

Source code would be something like this:

public interface IDiscountCalculator
{
    decimal Calculate(decimal productPrice, CustomerType customerType);
}

public enum CustomerType
{
    Standard = 0,
    Silver = 1,
    Gold = 2,
    Platinum = 3
}

So let’s examine some of the different ways we could test the discount functionality.

1. Testing using the UI (website)

In this scenario you basically need to run the website and the API, and navigate to the page where the discount is being displayed (e.g. view shopping cart). This means that you might eventually need to login, search for a product, add it to the shopping cart and then view the shopping cart in order to check if the discount is correct or not. Also, you need to do it for each customer type.

As you can imagine, this is not the most efficient way to test this functionality. We need to compile and run both the website and the REST API (authenticate user, etc).

2. Testing the API using a REST client

This is more efficient compared to the previous example (testing the UI) because you can skip all the steps mentioned before and invoke the service using a REST client such as Postman or SoapUI. You still need to create sample HTTP requests that might include HTTP headers (content type, authorization, etc), HTTP method and message body (JSON request object).

Depending on the service, it might take a while to configure the requests for each customer type. Also, we need to compile and run the REST API. Remember that in this scenario all we want to do is to calculate the discount for each customer type.

3. Testing using a console application

This is one of the simplest ways to run the test. There’s no need to use the UI to get to the page where the discount is displayed and there’s no need to create HTTP requests in order to invoke the API, i.e. we can test directly the discount functionality using .NET code. Also, console applications are faster to compile and run compared to an ASP.NET website.

4. Testing using an unit test framework

It’s basically as simple and fast as creating a console application – just add add your unit tests to a class library and you’ll be able to run the tests in a few seconds, using Visual Studio built-in functionality or a tool such as Resharper.

Conclusion

Saying “we don’t have time for unit tests” is deceiving. Giving that we need to to test our code somehow, ask yourself if the alternative to unit tests is easier and/or faster (creating a sample console app to run some tests, etc) – I’m pretty sure that in most of the cases the unit testing is the better option.

Implementing a basic IoC container using C#

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

Table of contents

  • References
  • Downloads
  • Continue reading

    Improving LINQ code reusability: Select method

    Select method is used to project each element of a sequence into a new form, i.e. it can be used to map a collection of one type to a collection of another type. In this article I’ll show you a simple approach that will allow you to reuse the code used in the Select method.

    Table of contents

    The Problem

    Consider the following model:

    Let’s suppose that you have a services layer, so you don’t want to expose your domain objects directly to the client applications. Instead you create a set of data contracts (or DTOs, if you prefer):

    At some stage you’ll have to convert those Domain objects to data contracts. This is a common way of doing it:

    var details = repository.All<Album>().Select(album => new AlbumDetail {
        AlbumId = album.AlbumId,
        Price = album.Price,
        Title = album.Title,
    
        ArtistId = album.ArtistId,
        GenreId = album.GenreId,
        ArtistName = (album.Artist == null) ? null : album.Artist.Name,
        GenreName = (album.Genre == null) ? null : album.Genre.Name
    });
    

    There is a problem with this approach – if you need to query the same collection but using different criteria you have to duplicate the code inside the Select method.

    Solution 1 – Creating a method for the mapping

    In order to reuse the code, we can create a method that converts Album objects (Domain) to data contract objects:

    private static AlbumSummary CreateAlbumSummary(Album album)
    {
        return new AlbumSummary {
            AlbumId = album.AlbumId,
            Title = album.Title,
    
            ArtistName = (album.Artist == null) ? null : album.Artist.Name
        };
    }
    
    private static AlbumDetail CreateAlbumDetail(Album album)
    {
        return new AlbumDetail {
            AlbumId = album.AlbumId,
            Price = album.Price,
            Title = album.Title,
    
            ArtistId = album.ArtistId,
            GenreId = album.GenreId,
            ArtistName = (album.Artist == null) ? null : album.Artist.Name,
            GenreName = (album.Genre == null) ? null : album.Genre.Name
        };
    }
    

    Using the code:

    var albums = Albums.Select(CreateAlbumDetail);
    var albumsByGenre = Albums.Where(x => x.GenreId == genreId).Select(CreateAlbumDetail);
    
    // alternative way
    var albums2 = Albums.Select(x => CreateAlbumDetail(x));
    var albumsByGenre2 = Albums.Where(x => x.GenreId == genreId).Select(x => CreateAlbumDetail(x));
    

    Solution 2 – Creating a generic ObjectMapper object

    The previous solution solves the code reusability problem, but there’s still a tight coupling between components. Abstractions should be used to implement loose coupling between components – in this case, to abstract the mapping code.

    Step 1: define a contract (interface) with a method that converts one object of type TSource to an object of type TDestination:

    public interface IObjectMapper
    {
        TDestination Map<TSource, TDestination>(TSource source);
    }
    

    Step 2: create a class that implements IObjectMapper (click to expand):

    public class ObjectMapper : IObjectMapper
    {
        private Dictionary<Type, Func<object, object>> Mappers = new Dictionary<Type, Func<object, object>>
        {
            { typeof(Tuple<Album, AlbumDetail>), CreateAlbumDetail },
            { typeof(Tuple<Album, AlbumSummary>), CreateAlbumSummary }
    
            // more mappings here
            // ....
        };
    
    
        public TDestination Map<TSource, TDestination>(TSource source)
        {
            if(source == null)
                return default(TDestination);
    
            Func<object, object> mapper = null;
            Type key = typeof(Tuple<TSource, TDestination>);
    
            if(Mappers.TryGetValue(key, out mapper))
            {
                var newObject = mapper(source);
                return (TDestination) newObject;
            }
    
            string errorMessage = string.Format("Invalid mapping (Source: {0}, Destination: {1})";,
                                                typeof(TSource).FullName, 
                                                typeof(TDestination).FullName);
            
            throw new InvalidOperationException(errorMessage);
        }
    
    
        private static object CreateAlbumDetail(object source)
        {
            var album = source as Album;
    
            return new AlbumDetail {
                AlbumId = album.AlbumId,
                Price = album.Price,
                Title = album.Title,
    
                ArtistId = album.ArtistId,
                GenreId = album.GenreId,
                ArtistName = (album.Artist == null) ? null : album.Artist.Name,
                GenreName = (album.Genre == null) ? null : album.Genre.Name
            };
        }
    
        private static object CreateAlbumSummary(object source)
        {
            var album = source as Album;
    
            return new AlbumSummary {
                AlbumId = album.AlbumId,
                Title = album.Title,
                
                ArtistName = (album.Artist == null) ? null : album.Artist.Name
            };
        }
    }
    

    Example 1: Using LINQ

    Using the mapper in a LINQ expression – convert an Album collection to an AlbumSummary collection:

    IObjectMapper mapper = new ObjectMapper();
    
    IEnumerable<AlbumSummary> summaries = repository.All<Album>()
                                            .Select(mapper.Map<Album, AlbumSummary>);
    

    Example 1: Mapping a single object

    Using the mapper for a single object:

    var album = new Album {
        AlbumId = 1,
        Price = 10.0m,
        Title = "The Dreamer",
        Artist = new Artist { ArtistId = 1, Name = "José James" },
        Genre = new Genre { GenreId = 1, Name = "Jazz" }
    };
    
    IObjectMapper mapper = new ObjectMapper();
    
    AlbumDetail albumDetail = mapper.Map<Album, AlbumDetail>(album);
    

    Unit Testing

    Some NUnit tests:

    [Test]
    public void Given_a_non_existing_mapping_when_mapping_object_then_should_throw_InvalidOperationException()
    {
        // arrange
        IObjectMapper mapper = new ObjectMapper();
        var albumDetail = new AlbumDetail();
    
        // act/assert
        Assert.Throws<InvalidOperationException>(() => 
            // non-existing mapping
            mapper.Map<AlbumDetail, AlbumSummary>(albumDetail)
        );
    }
    
    [Test]
    public void Given_an_album_when_mapping_to_album_summary_should_equals_expected_album_summary()
    {
        // arrange
        IObjectMapper mapper = new ObjectMapper();
        
        var album = new Album {
            AlbumId = 4,
            Price = 10.0m,
            Title = "Heritage",
            Artist = new Artist { ArtistId = 4, Name = "Opeth" },
            Genre = new Genre { GenreId = 4, Name = "Metal" }
        };
    
        var expectedAlbumSummary = new AlbumSummary {
            AlbumId = 4,
            ArtistName = "Opeth",
            Title = "Heritage"
        };
        
        // act
        AlbumSummary albumSummary = mapper.Map<Album, AlbumSummary>(album);
        
        // assert
        Assert.AreEqual(albumSummary, expectedAlbumSummary);
    }
    

    Final thoughts

    In this article you learned how to reuse the code used in the Select method, and how you can use that code to map single objects. But writing mapping code is tedious and time consuming. There are mapping tools out there that can make your life easier – AutoMapper is one of them. I’ve used it in the past and I definitely recommend it. So, why use Automapper? Quoting their website:

    “What makes AutoMapper interesting is that it provides some interesting conventions to take the dirty work out of figuring out how to map type A to type B. As long as type B follows AutoMapper’s established convention, almost zero configuration is needed to map two types”

    “Mapping code is boring. Testing mapping code is even more boring. AutoMapper provides simple configuration of types, as well as simple testing of mappings”

    References

    Downloads

    Download the demo project (VS2010): LINQ-Select.zip

    Technorati Tags: , , ,