Design for testability – WCF proxies

Recently I spent some time participating in projects involving Silverlight, Prism etc and there are couple of interesting things I’ve came up with during that period which I would like to share with the community in a form of a couple of blog posts showing the “enhancements” I did in our Prism based implementation.

I was thinking a lot where to start and as a result of that I have decided to start with something small but useful. I’ll focus in this blog post on Silverlight, but this simple trick is usable in any other client technology making WCF calls. So, here we go…

How to have testable Silverlight code depending on WCF calls

Why reinventing the wheel?

In order to make sure that trivial thing I’ll be writing about today was not already covered by someone I did my Bing homework and came out with two approaches you might want to check out:

• Derik Whittaker adapter based solution Abstracting away Dependencies for Simpler code 
• Fake host based solution http://www.silverlightshow.net/items/Deep-dive-into-WCF-part-1-TDD.aspx

While I find both of them to be perfectly acceptable solution I think they are suboptimal due to different reasons.

In case of first solution (which based on screen cast comments is the way a lot of people do) there is one more layer of abstraction to be maintained.
In typical DDD style application we have DB tables mapped to domain entities which are (usually) flattened in web server layer where the WCF service contracts behave as application level services with client centric shapes and behaviors. With this approach we need another interface with either its own behaviors or just copy pasting the service contract and additional adapter class which delegates the calls to proxy. IMHO, layer of abstraction down –> maintainability level up

In case of second solution, my objections are similar to the one I have regarding service locator. Abstracting the “locator” (servicehost) leads to opaque dependencies on a consumer level which are much harder to be unit tested and understood. On top of that, I find this solution also to introduce additional complexity with defining factories, providers etc is IMHO are overkill for simple “TDD enable WCF proxy dependable code”

Duct tape programmer solution

Regardless of how much I disagree with Joel on the value of the duct tape programmer, I couldn’t get away from the fact that my solution compared with other two (full of big patterns and cool code) looks exactly like it is been done by the duct tape programmer – me. That’s ok, simplicity is #1 design criteria for me.

In this solution I won’t be using therefore any patterns but instead I would just rely on one hack and one small convention to get quickly testable code which is easier to be maintained and understood (compared to other approaches).

Demoware “WCF proxy being called directly” sample

So, here’s the setup for today post. We are having application which goal is to show the names of the users having salary greater then $1000.

Client is implemented using Silverlight accessing the user data on a server side by making a WCF service calls.

In order to do that I used vanilla Silverlight solution (didn’t want to use Prism here) consisting of two projects:

• Web application containing a UserService.svc WCF service and hosting a silverlight app.
• Silverlight application which has UserService service proxy and MainPage showing the names of users in a ListBox.

UserService.svc

using System.Collections.ObjectModel;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Activation;

namespace SilverlightApplication.Web
{
    [ServiceContract(Namespace = "http://blog.vuscode.com/200911")]
    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
    public class UserService
    {
        [OperationContract]
        public Collection<User> GetUsers()
        {
            return new Collection() 
            { 
                new User { Id = 1, Name = "Nikola", Salary = 1000 },
                new User { Id = 2, Name = "John", Salary = 2000 },
                new User { Id = 3, Name = "Jane", Salary = 3000 },

            };
        }
    }

    [DataContract]
    public class User
    {
        [DataMember]
        public int Id { get; set; }

        [DataMember]
        public string Name { get; set; }

        [DataMember]
        public decimal Salary { get; set; }
    }
}

Nothing important here: In one file OperationContract defining a method GetUsers returning the collection of users (User DataContratct being defined in the same file)

Let’s move on…

MainPagePresenter? Where’s the MainPageViewModel?

Well, I was surprised that many people I spoke with recently think MVVM is not the only “right” way to do SilverlightWPF development and I tend to disagree with that. While MVVM has its own values (it is also presentation pattern of my choice too) you can do MVC or MVP (both passive view and supervising controller) equally successfully like you can do it in desktop applications (speaking of which, Silverlight for me is desktop app deployed through browser) If you don’t trust me, ask Jeremy. That’s why I ended with some implementation for this

So, in order to spice up this blog post a bit I ended with MVP- like implementation with MainPagePresenter implemented like this

using System.Windows;
using SilverlightApplication.UserServiceProxy;
using System.Linq;

namespace SilverlightApplication
{
    public class MainPagePresenter
    {
        private FrameworkElement view;
        
        public MainPagePresenter(FrameworkElement view)
        {
            this.view = view;
        }

        public void Init() 
        {
            UserServiceClient proxy = new UserServiceClient();
            proxy.GetUsersCompleted += (sender, e) =>
                                       {
                                           this.view.DataContext = e.Result.Where(p => p.Salary > 1000);
                                       };
            proxy.GetUsersAsync();
        }
    }
}

Constructor here is more interesting because it accepts the instance with type inheriting from FrameworkElement (pretty much most of controls in Silverlight) and stores its pointer to a view filed. In other words, abstraction of a view is being injected into the presenter just instead of the IView I am being smart here and using the FrameworkElement as abstraction  every view (user control implements).

It is the good old demoware type of code you’ve seen on a lot of places with proxy being instantiated in the method body spiced up with cool lambda implementation of async event handler (which any better presenter would use to scare the session attendees) and with a simple linq statement filtering the result set to exclude the rows lower then 1000.

The magic in this code starts when view FrameworkElement.DataContext gets set by the filtered result set. Presenter doesn’t have a clue about what specific control view is but still it is able to set its common property to a value generating desired view behavior.

Wiring  up the view and the presenter

There’s really big religious war on the IT sky regarding who is created first (view or viewmodel presenter) and the allowed level of coupling between them. I have my own take on that to which I would dedicate a separate blog post (it is important subject) but for the sake of this blog post let say that it is perfectlly fine that view is created first and that it has direct reference to presenter.

That’s how the view (MainPage.xaml file) ended being implemented like this

using System.Windows;
using System.Windows.Controls;

namespace SilverlightApplication
{
    public partial class MainPage : UserControl
    {
        MainPagePresenter presenter;

        public MainPage()
        {
            InitializeComponent();
            this.presenter = new MainPagePresenter(this);
            this.Loaded += new RoutedEventHandler(MainPage_Loaded);
        }

        void MainPage_Loaded(object sender, RoutedEventArgs e)
        {
            this.presenter.Init();
        }
    }
}

As you can see in a page constructor a instance of the presenter was created with a pointer to the page itself being passed to presenter (which if you look up would be held as a presenter field and used in Init method).

Then Loaded event handler is being created (don’t put any UI related code in the constructor because it is not guaranteed that UI would be ready when that line would be executed) and in it presenter.Init() method invoked. In other word, view said to presenter “Please set me up!”

Markup code

Did I tell you how much I like WpfSilverlight? Check the simplicity of the markup code!

    <Grid x:Name="LayoutRoot" Background="White">
        <ListBox
                 Name="listBox1"
                 ItemsSource="{Binding}"
                 DisplayMemberPath="Name" />
    </Grid>

Setting ItemsSource to {Binding} effectively said to control “Bind to your own DataContext” (key moment specific to WPFSL), and DisplayMemeberPath Name value can be read “whatever the collection would be in DataContext, collection item would have a property called Name”

Simple, elegant and powerful!

Runtime experience

Wow, so much talk about such a simple thing. Ok, I proved it working

My duct tape based solution

is based on the simplest possible solution I was expecting that WCF supports out of box: IXYZServiceClient interface contracting in abstract way proxy behavior. 

To my surprise I have realized that WCF generated proxy is not creating that interface (IUserServiceClient in this example) so I decided to created in manually.

Doing things WCF team should have already done

I’ve clicked on Show All files icon (to see hidden proxy files) and opened Reference.cs file containing proxy c# code.

Then I found UserServiceClient class definition

Right click it and pick to extract interface (R# can help with this too)

I pick only the members I care to be abstracted (leaving unchecked all of the WCF infrastructure members)

and ended with this

Obviously not good solution because next proxy refresh and all this is gone, so there are two problems:

1. How to preserve interface
2. How to avoid having manually to add interface implementation to generated ServiceClient class.

In order to solve problem #1, I have created then a folder with the same name as the proxy and drag and drop the interface to that folder. First problem solved!

In order to solve problem #2, I am utilizing the fact that the ServiceClient is generated as partial class so I create in the new folder  another partial UserServiceClient class implementing the IUserServiceClient interface. Here’s how that class look like

namespace SilverlightApplication.UserServiceProxy
{
    public partial class UserServiceClient : IUserServiceClient
    {
    }
}

I hope now you can get the reason why I was a folder with the same name as the proxy –> the namespaces of types and interfaces in that folder are matching out of the box the ones in the proxy class

And here's the solution (for visual learners like me)

To summarize the solution:

• I’ve created the IServiceClient by simple extracting the facade of the proxy client interface
• I’ve created partial UserServiceClient which is only attaching the interface to proxy
• Both of files are  not destroyed with proxy regeneration.
• If the WCF service contract changes over the time, regenerating of new IUserServiceClient is trivial task taking less then 15 seconds.

Duct tape solution at its best!

Modifying presenter

using System.Windows;
using SilverlightApplication.UserServiceProxy;
using System.Linq;

namespace SilverlightApplication
{
    public class MainPagePresenter
    {
        private FrameworkElement view;
        private IUserServiceClient userServiceClient;
        
        public MainPagePresenter(FrameworkElement view, IUserServiceClient userServiceClient)
        {
            this.view = view;
            this.userServiceClient = userServiceClient;
        }

        public void Init() 
        {
            this.userServiceClient.GetUsersCompleted += (sender, e) =>
                                       {
                                           this.view.DataContext = e.Result.Where(p => p.Salary > 1000);
                                       };
            this.userServiceClient.GetUsersAsync();
        }
    }
}

As you can tell I’ve made two changes:

• added another parameter to the constructor injecting the newly created IUserServiceClient interface
• Modified Init method to replace proxy instantiation with usage of injected client proxy abstraction.

Modifying the view

Usually I wouldn’t modify the view but instead rely on IoC container to inject the UserServiceClient instance, but in order to keep this post focused I won’t be using IoC here (you’ll see it in one of my future posts showing my Prism enhancements) so I needed to make a simple change in a page constructor

        public MainPage()
        {
            InitializeComponent();
            this.presenter = new MainPagePresenter(this, new UserServiceClient());
            this.Loaded += new RoutedEventHandler(MainPage_Loaded);
        }

Nothing special, just added new UserServiceClient() to the parameters being passed to a presenter.

Running the app again

Yeap, still works

Where’s the unit test?

Well, this blog post is long enough (and it is late enough ) so I would skip the unit test example this time because it is fairly trivial to be written now when we have interface of the service proxy.

Summary

In this blog post I showed another way how to easy introduce a layer of simple abstraction between the WCF service proxy and the code consuming it.

I find the advantage of my approach VS the two of others in its simplicity and maintainability but again considering I “invented it” that comes as no surprise to me

Source code of the end solution can be downloaded from here.

Say no to ServiceLocator

(Disclaimer: As I stated here, while I find over the time ServiceLocator based code to be a bad practice, I do understand the need for its usage in certain brown-field  scenarios as a way of reducing the risk while introducing the IoC.)

In my previous Nikola’s laws of dependency injection blog post I stated couple of IoC laws based on my experience:

1. Store in IoC container only services. Do not store any entities.
2. Any class having more than 3 dependencies should be questioned for SRP violation
3. Every dependency of the class has to be presented in a transparent manner in a class constructor.
4. Every constructor of a class being resolved should not have any implementation other then accepting a set of its own dependencies.
5. IoC container should be explicitly used only in Bootstrapper.
   Any other “IoC enabled” code (including the unit tests) should be completely agnostic about the existence of IoC container.

The #5 (“IoC container should be a ghost even in unit tests”) resulted with couple of blog post comments and emails asking for clarification what I mean by that.

In short:

Say no to Service Locator Opaque dependencies!

Radenko Zec posted in comment example which with very slight modifications (to reflect better my Law #1) looks like this…

There are 4 projects in the solution used in today blog post:

1. ClassLibrary containing the two classes where:
   - UserRepository is having dependency on other
   - LoggingService (implementing the ILoggingService)
2. ConsoleApplication1 simulating the production usage and containing the:
   - bootstrapper class (defining IoC mappings) and the
   - Program.cs (main console file which would execute our functionality
3. Infrastructure containing my naive implementation of Unity container adapter with the
   - IContainer abstraction of the Unity container,
   - UnityContainerAdapter class implementing the adapter design pattern adapting the UnityContainer to IContainer 
   - UnityContainer service locator class,
4. TestProject1 containing the unit test for the ClassClibrary1 - UserRepositoryTest

Before diving into the Radenko’s sample implementation let me restate my point by saying that

• none of the classes using IoC (in this simple example UserRepository) should NOT be aware at all of IoC and
• UserRepositoryTest should NOT have testfixture setup methods filling the container

Service locator based implementation

As given in Radenko’s comment example Bootstrapper class registers the mappings

namespace ConsoleApplication1
{
    using ClassLibrary1;
    using Infrastructure;

    public static class Bootstraper
    {
        public static void SetUp()
        {
            IContainer cont = UnityContainer.Instance();
            cont.Register<ILoggingService, Loggingservice>();
        }
    }
}

Here’s the simple implementation of that LoggingService (not very important for this blog post but still to be clear)

namespace ClassLibrary1
{
    using System;
    using System.Diagnostics;

    public class LoggingService : ILoggingService
    {
        public void Log(string message)
        {
            Debug.WriteLine(string.Format("LOGGED: {0}.", message));
        }
    }
}

And here’s the class being dependable on that LoggingService

namespace ClassLibrary1
{
    using Infrastructure;

    public class UserRepository
    {
        public void Delete (int userId)
        {
            IContainer cont = UnityContainer.Instance();
            ILoggingService loggingService = cont.Resolve<ILoggingService>();
            loggingService.Log(string.Format("User with id:{0} deleted", userId));
        }
    }
}

So, as you can see in a given example Delete method is implemented like this:

• get ServiceLocator (singleton instance of the UnityContainerAdapter)
• using the ServiceLocator retrieve from IoC container component mapped to ILoggingService
• use that component to log a message.

What is wrong with this code?

• It violates the Separation of Concerns Single Responsibility Principle  – UserRepository taking care about IoC, instance resolution etc
• It good example of opaque dependency injection which hides sometime the set of dependencies component has.

  Looks like “not a big deal” but when you face the class with couple of thousands of lines and you have to read them ALL just to get the list and repeat that couple of times, it is a big deal. (Yes, I do agree with you that having that long classes is atrocity of its own kind, but seeing it all the time in my world)

(Couple of more reasons but let’s just continue our journey…)

Here’s how the production usage would look in this example

namespace ConsoleApplication1
{
    using ClassLibrary1;

    class Program
    {
        static void Main(string[] args)
        {
            Bootstraper.SetUp();
            UserRepository userRepository = new UserRepository();
            userRepository.Delete(3);
        }
    }
}

No magic there: code issues a command to bootstrapper to initialize IoC, create a instance of UserRepository and invoke its Delete method.

The last thing left is the example of unit test one might write with this code

namespace TestProject1
{
    using Microsoft.VisualStudio.TestTools.UnitTesting;
    using ClassLibrary1;
    using Infrastructure;
    using Rhino.Mocks;

    [TestClass]
    public class UserRepositoryTest
    {
        private ILoggingService loggingService;

        [TestInitialize]
        public void Would_Be_Executed_Before_Every_Test()
        {
            var serviceLocator = UnityContainer.Instance();
            loggingService = MockRepository.GenerateMock<ILoggingService>();
            serviceLocator.Register(loggingService);
        }


        [TestMethod]
        public void Delete_InCaseOfValidUserID_WouldLoggAMessage()
        {
            // arrange
            var userId = 3;
            loggingService.Expect(p => p.Log(string.Empty)).IgnoreArguments();

            // act
            UserRepository userRepository = new UserRepository();
            userRepository.Delete(userId);

            // assert
            this.loggingService.VerifyAllExpectations();
        }
    }
}

This is not a blog post on unit testing so just a short discussion what the test does :

In Test initialization the singleton instance of IoC containe is retrieved. Then an RhinoMock dynamic mock class of ILoggingService is created and then injected into the container. Summarized: we stored something in a container before the test execution, because we know from the source code that it would be used in SUT.

The test itself is very simple:

• Arrange defines what is the expected behavior of the logging service which is supposed to be caused as a result of SUT activity
• Act creates an instance of the UserRepository and invokes the delete method
• Arrange verifies that the expected behavior of the logging service occurred.

Nothing much –> just another example of behavior unit testing.

What is wrong with this unit test?

Well, I wrote them “a few” like this and it works well but with certain pain points which the more test you write the more painful become:

1. It prevents black box unit testing.
   
   I tend lately to think about unit tests more as of a functional specifications and due to that I try always to test the class based on defined functional requirements WITHOUT looking in the implementation (to stay as objective as I can). Only once I cover ALL functional cases, I tend to do a quick check of the test coverage and focus on removing the code not being tested (all reqs satisfied and code not used –> potential overkill)
2. Prevents effective unit testing
   
   Sooner or later, with this code you end with writing test following the “run the test, get what is missing, add a mapping, run it again, get what is missing, add a line…”  which IMHO ends to be very slow process.
3. Makes Fixture'SetUp very big and clunky.
   
   Here we set up one dependency, but imagine hundreds of unit tests with their own many dependencies dig up in the code and how big this section would become…

   In the past I was trying to tackle that by creating special bootstrapper classes filling the IoC container with test infrastructure stubs and with using AutoMockingContainer (still not completely sure about should I do that or not – another blog post) but the end result is that I got more code to be maintained and which is getting broken wevery time production interfaces change etc.

4. Decreases test readability
   
   If you want take tests as a sort of functional specification (and you should) pretty often you would want to “read the tests” in order to get what and how the SUT works. Having a bunch of setup code outside of the method being read makes that much harder.

All the right solutions are always simple as possible

In order to comply to law #5 I need to refactor the UserRepository implementation by removing IoC container from it and in order to comply law #3 I need to explicitly enlist in a constructor all of its dependencies.

So, following those two rules I end with this code:

namespace ClassLibrary1
{
    public class UserRepository
    {
        private readonly ILoggingService loggingService;

        public UserRepository(ILoggingService loggingService)
        {
            this.loggingService = loggingService;
        }

        public void Delete (int userId)
        {
            this.loggingService.Log(string.Format("User with id:{0} deleted", userId));
        }
    }
}

As you can see all I did was to transform the ServiceLocator type of code to dependency injection type of code where there is no more SoCSRP violation and where the UserRepository is unaware of IoC (no single line related to it).

For the folks with concerns that this could result with some very long constructors with too many dependencies I suggest checking out Auto Mocking Container and/or:

Law #2 Any class having more than 3 dependencies should be questioned for SRP violation

Let see the unit test for this class

namespace TestProject1
{
    using Microsoft.VisualStudio.TestTools.UnitTesting;
    using ClassLibrary1;
    using Rhino.Mocks;

    [TestClass]
    public class UserRepositoryTest
    {
        [TestMethod]
        public void Delete_InCaseOfValidUserID_WouldLoggAMessage()
        {
            // arrange
            var userId = 3;
            
            var loggingService = MockRepository.GenerateMock<ILoggingService>();
            loggingService.Expect(p => p.Log(string.Empty)).IgnoreArguments();
            // act
            UserRepository userRepository = new UserRepository(loggingService);
            userRepository.Delete(userId);
            
            // assert
            loggingService.VerifyAllExpectations();
        }
    }
}

As you can see above:

• There is no more initialization routine – all of the code related to this test is in one place.
• Every test initialize only what it needs (no big chunk of initializing union of  of mappings all tests need)
• While writing the test the C# compiler informs me that the UserRepository needs a logging service. If I don’t provide it test won’t compile.
  
  That’s how I can avoid looking at the source code in order to get what dependency class has,
• As for law #5, notice that in my unit test there is NO IoC code at all (even infrastructure component is not referenced anymore).
  
  IoC has to be for us when needed but also it has to stay away from our work. Full orthogonality. Period.

How the production code looks with new approach?

Almost the same

namespace ConsoleApplication1
{
    using ClassLibrary1;

    using Infrastructure;

    class Program
    {
        static void Main(string[] args)
        {
            Bootstraper.SetUp();
            var unityContainer = UnityContainer.Instance();

            var userRepository = unityContainer.Resolve<UserRepository>();
            userRepository.Delete(3);
        }
    }
}

The main difference is that I’ve used the unity to resolve UserRepository and performs (by that) automatic object graph wire up. It may look like that we ended with the same thing just in other class and that is correct (partially)!

It is correct in a sense that if you think for a second about the real world systems you have many classes chained in cross dependencies in which case it is in your interest to push out from all of them the IoC resolution and let the IoC container of your choice do the auto wire up magic.

It is not correct in a sense that in a most part of your system (usually matching the area you want to test( you what have implict injection and not this explicit. For example, if your CompanyRepository would need a UserRepository (not claiming it has real sense to be done) the CompanyRepository would just have in its constructor IUserRepositoryUserRepository and that’s it.

Conclusion

Reafactoring from service locator to real dependency injection type of code is very easy if not trivial but do require a small “bing!” in your head to just realize it.

After switching to this practice, my tests get much lighter, faster, easier to read and maintain.

Radenko, I hope I answered your question

Here’s a sample code I used in today’s blog

Dependency injection in real world

Patrick left a comment on one of my previous blog posts asking a couple of very interesting questions that I’ve been asking myself too:

Is service locator legitimate way of doing IoC?

(I’ll use example code from that blog post as a base for my today blog post so in case you are idle enough you can go and check it out)

Dependency injection primer

Let me start with an example how “real” dependency injection implementation code from my blog post could look like:

using System;
using System.Collections.Generic;

namespace Example.UserManager
{
    public class UserManagerIoC
    {
        private readonly IUserProvider userProvider;

        public UserManagerIoC(IUserProvider userProvider)
        {
            this.userProvider = userProvider;
        }

        public int NumberOfUsersActiveInLast10Days(string userName)
        {
            var userCollection = this.userProvider.GetUserCollection();
            int result = 0;
            foreach (User user in userCollection)
            {
                if (user.Name.StartsWith(userName) && user.LastActivity > DateTime.Now.AddDays(-10))
                    result++;
            }
            return result;
        }
    }
}

As we can see from the simple code above, code has one constructor which accepts the IUserProvider parameter and then stores its pointer to a field  so it can be used  later in a method which performs some kind of business logic.

Key concept here to be noticed is that class have literally no clue where from and how userProvider would get injected.

How DI based unit test looks like?

I’ll use Microsoft Unity and Rhino mocks to write a test for the dependency injection primer.

Here it is:

using System.Collections.Generic;
using Example.UserManager;
using Microsoft.Practices.Unity;
using NUnit.Framework;
using Rhino.Mocks;

namespace UserManager.Test.IoC
{
    [TestFixture]
    public class UserManagerTestIoC
    {
        private MockRepository mockRepository;
        private IUnityContainer unityContainer;

        [SetUp]
        public void Test_Init()        
        {
            this.mockRepository = new MockRepository();
            this.unityContainer = new UnityContainer();
        }

        [Test]
        public void GetActiveUsers_TestCaseOfZeroUsers_WouldReturnEmptyCollection()
        {
            var userProvider = this.mockRepository.DynamicMock<IUserProvider>();
            // injecting to unity container mocked instance of user provider
            this.unityContainer.RegisterInstance(userProvider);
            
            using (this.mockRepository.Record())
            {
                Expect.Call(userProvider.GetUserCollection())
                    .Return(new List<User>());
            }
            using (this.mockRepository.Playback())
            {
                // using IoC container for UserManager construction 
                var userManager = this.unityContainer.Resolve<UserManagerIoC>();
                
                // and then performing tested code 
                int numberOfUsers= userManager.NumberOfUsersActiveInLast10Days("X");
                Assert.IsTrue(numberOfUsers == 0);
            }
        }  
    }
}

What I did in that test:

• I am instantiating UnityContainer in test set up to be used as IoC container.
• In first line of test  method I am using Rhino mocks to create mock of IUserProvider and then I inject that mock to Unity IoC container
• In a first line of recording block, I set expectation that empty user collection would be returned
• In playback block, I get an instance of UserManagerIoC class by using IoC container Resolve factory method. (KEY POINT)
• IoC container would then:
  • examine the constructor of UserManagerIoC class,
  • see that IUserProvider parameter is requested
  • try to find in IoC container registered service implementing IUserProvider interface
  • mocked instance we injected at the beginning of the test would be found
  • mocked instance would be injected to UserManagerIoC
• Method would be executed and the expected number of users checked

NOTE #1: You could get away from explicit dependency mocking by using AutoMockingContainer but I decide to do it anyhow in this post in order to increase example readability.

NOTE #2: You could also opt to use var userManager = new UserManager(userProvider) but this is not something typically you would do because userProvider can have it’s own dependencies and so on… Not using IoC container in the test would mean not using one of its most important features: auto dependency resolution.

Dependency injection upsides and downsides

As we can see, we were able to keep UserManager light and ignorant about IoC infrastructure, while utilizing the benefits dependency injection provides us (increased testability in this example)

Still there are couple of problems (not sure if I can call them like this) related to this implementation which I’ve witnessed in last couple of months and which can be summarized as:

• Brownfield scenarios

  UserManager is already existing class built without having dependency injection on mind (no constructor exposing abstracted dependencies). While it is hard to sell the business value of refactoring UserManager internals to expose dependencies through constructor (sell tagline: to test it) it is mission impossible getting approval for updating all of the million places  currently doing the UserManager um = new UserManager() to become unityContainer.Resolve<UserManager>() (Sith language : “What’s the business value?”) and without that change no DI going to happen.

• Code monkey scenarios
  
  Vast majority of developers I know don’t get the IoC, TDD etc, which means that one would spend ton of time answering the

  “Why I can not just new the instance?”, “This is clearly an overkill…”, “Here it is him with his damn patterns making my life miserable”, “Why I need to decouple DB from my  unit tests at all?”..

  Although this reason might look “not-so-important”, if you are not lucky to work in TDD friendly environment, if you are working in company which DEV teams span across the globe this could be real show stopper.

• “TDD == unit test”
  
  If you are doing unit tests AFTER the code is been done then it is very hard to sell to PMs the need for “all that complexity”.

  In other words, if they don’t get that in TDD the most important thing is not the “T” (test) but the “DD” (driven design) whole DI thing start to get harder to be sold

• “Why IoC framework X?”
  
  ”Why UnityContainer?” “Why not Castle?” “Why not Spring?” “Why not StructureMap?” “On my previous job I worked with XYZ and it is the best…”

ServiceLocator based dependency injection

Luckily, I think I found a way how to go around the restrictions mentioned above with keeping the dependency injection in place and high testability. I’ve wrote in more details in my DFT blog post series so here I’ll just summarize it…

The key points that solution has to achieve are:

1. Core code implementation has to utilize dependency injection
2. Code has to be “open for testing” but “close for development”  (yes, I am aware how stupid this might sound and it it stupid thing – details bellow )
3. DI enabling existing code is not allow to cause any breaking compatibility issues (KIC - “keep it cheap” design principle)
4. No dependency on any particular IoC framework
   

Lets take a look at the same primer I’ve done with DI this time implemented using service locator

using System;
using Facade;

namespace Example.UserManager
{
    public class UserManagerSL
    {
        private readonly IUserProvider userProvider;

        public UserManagerSL(): this (ServiceLocator.Retrieve<IUserProvider>())
        {
        }

        internal UserManagerSL(IUserProvider userProvider)
        {
            this.userProvider = userProvider;
        }

        public int NumberOfUsersActiveInLast10Days(string userName)
        {
            var userCollection = this.userProvider.GetUserCollection();
            int result = 0;
            foreach (User user in userCollection)
            {
                if (user.Name.StartsWith(userName) && user.LastActivity > DateTime.Now.AddDays(-10))
                    result++;
            }
            return result;
        }
    }
}

Main differences (compared to dependency injection primer) are:

• We still have public parameter less constructor
  
  That parameter less  constructor uses ServiceLocator to retreive instace of IUserProvider on a same way UnityContainer retrieved it in previous test.

  ServiceLocator is just a Facade wrapper around IoC container encapsulating the type of container and hiding not used features.

  Achieved design goal: “Keep it cheap”
  
  Achieved design goal: “No dependency on particular IoC framework”

• In some bootstrapper class tied to app start event I will have to define ServiceLocator mapping for service implementing the IUserProvider so the code would work normally like it was working before the dependency injection
  
  
• Constructor taking IUserProvider parameter is now internal.
  
  The assembly containing UserManagerSL class would contain next attribute

  [assembly: InternalsVisibleTo("UserManager.Test.SL")]

Result of this attribute would be that this constructor would be:

- visible to test assembly containing test methods using UserManagerSL

- not visible to any code outside of that test assembly (none of the “core DEV” would be aware of it)

Achieved design goal: “Open for test, close for development”

Achieved design goal: “Dependency injection used in code”

How ServiceLocator based test looks like?

Here are two examples how the service locator code can be tested..

“White box” service locator test style

using System.Collections.Generic;
using Example.UserManager;
using Facade;
using NUnit.Framework;
using Rhino.Mocks;

namespace UserManager.Test.SL
{
    [TestFixture]
    public class UserManagerTestSL
    {
        private MockRepository mockRepository;
        private IUserProvider userProvider;

        [SetUp]
        public void Test_Init()        
        {
            this.mockRepository=new MockRepository();

            // registering mock of IUserProvider with ServiceLocator
            this.userProvider = this.mockRepository.DynamicMock<IUserProvider>();
            ServiceLocator.InjectStub(this.userProvider);
        }

        [Test]
        public void GetActiveUsers_TestCaseOfZeroUsers_WouldReturnEmptyCollection_WithSL()
        {
            using (this.mockRepository.Record())
            {
                Expect.Call(this.userProvider.GetUserCollection())
                    .Return(new List<User>());
            }
            using (this.mockRepository.Playback())
            {
                // using internal constructor
                var userManager = new UserManagerSL();
                int numberOfUsers = userManager.NumberOfUsersActiveInLast10Days("X");
                Assert.IsTrue(numberOfUsers == 0);
            }
        }
    }
}

In this testing style we feed the service locator with the list of internal dependencies we know it is been used by the tested code and then in our test method we totally don’t care about dependency injection (constructors used are empty, no service locator usage anywhere outside of SetUp method)

I personally don’t like this style of testing (based on intimate knowledge of tested code) but I’ve seeing it working in the past.

Using internal constructor

Second approach is based on the fact that internal constructor is accessible to test assembly which makes test built on this way very simple

using System.Collections.Generic;
using Example.UserManager;
using NUnit.Framework;
using Rhino.Mocks;

namespace UserManager.Test.SL
{
    [TestFixture]
    public class UserManagerTestSL
    {
        private MockRepository mockRepository;

        [SetUp]
        public void Test_Init()        
        {
            this.mockRepository=new MockRepository();
        }

        [Test]
        public void GetActiveUsers_TestCaseOfZeroUsers_WouldReturnEmptyCollection()
        {
            IUserProvider userProvider = mockRepository.DynamicMock<IUserProvider>();

            using (mockRepository.Record())
            {
                Expect.Call(userProvider.GetUserCollection())
                    .Return(new List<User>());
            }
            using (mockRepository.Playback())
            {
                // using internal constructor
                var userManager = new UserManagerSL(userProvider);
                int numberOfUsers = userManager.NumberOfUsersActiveInLast10Days("X");
                Assert.IsTrue(numberOfUsers == 0);
            }
        }
    }
}

In this example we don’t use at all service locator. Instead we simply inject mocked instance of user provider to internal constructor. All of the downsides of this approach (mentioned in dependency injection note #2) are applicable here to.

Using dependency injection

The best thing with my service locator based design approach is that while some of the “not so TDD skilled” developers can do testing on the first two ways, “TDD skilled” developer can still write exactly the same test as the one given in the dependency injection section of this blog post.

Check it for yourself:

        [Test]
        public void GetActiveUsers_TestCaseOfZeroUsers_WouldReturnEmptyCollectio_IoC()
        {
            var userProvider = this.mockRepository.DynamicMock<IUserProvider>();
            // injecting to unity container mocked instance of user provider
            ServiceLocator.InjectStub(userProvider);

            using (this.mockRepository.Record())
            {
                Expect.Call(userProvider.GetUserCollection())
                    .Return(new List<User>());
            }
            using (this.mockRepository.Playback())
            {
                // using IoC container for UserManager construction 
                var userManager = ServiceLocator.Retrieve<UserManagerSL>();

                // and then performing tested code 
                int numberOfUsers = userManager.NumberOfUsersActiveInLast10Days("X");
                Assert.IsTrue(numberOfUsers == 0);
            }
        }  

Summary

Most of the blog posts I’ve seen present an ideal “perfect day” situation setup  for writing the test which is not always the case in real world.

In this kind of “not-so-perfect” situations, service locator based solution I’ve presented in that blog post allowed me to increase testability and introduce TDD into existing code bases and environments not so much interested in the TDD.

Source code for this blog post can be found here.