Geoffrey Vandiest Blog

One of the major flaws in an un-testable design is the very tight coupling between the UI and the actual domain and/or presentation logic. Our typical ASP.NET applications are difficult to test, because much of the logic is contained within the codebehind files, which derive from Web.UI.Page, which needs an HttpContext, which is difficult to mock. Furthermore, the output of the methods in the codebehind is often not easily-testable, because it's a side-effect (such as calling DataBind() on a GridView).

This same problem exists in windows forms: How do you test the logic inside the form when you are unable to control the input & output of the UI? Let’s examine the following code sample.

   1:  public partial class LoginForm : Form

   2:  {

   3:      const string AUTHNETICATION_FAILED = "Authentication failed!";

   4:      public LoginForm()

   5:      {

   6:          InitializeComponent();

   7:      }

   8:   

   9:      private void LoginButton_Click(object sender, EventArgs e)

  10:      {

  11:          var membershipService = new MembershipService();

  12:          

  13:          if (membershipService.Authenticate(

  14:                                   UserNameText.Text,   

  15:                                   PasswordText.Text

  16:                                   )

  17:                )

  18:          {

  19:              MainForm form = new MainForm();

  20:              this.Hide();

  21:              form.Show();        

  22:          }

  23:          else

  24:          {

  25:              MessageLabel.Text = AUTHNETICATION_FAILED; 

  26:          }

  27:      }

  28:  }

Apart from being a pretty naïve implementation of a login form, this code is also hard to test. It’s design contains several smells of un-testable design. First of all it instantiates his Services directly, making it impossible to inject his dependencies through test doubles. Another problem is how can we test that; when the authentication was successful, the MainForm is shown?

By applying what we learned earlier we could already make our SUT more testable:

   1:  public partial class LoginForm : Form

   2:  {

   3:      const string AUTHENTICATION_FAILED = "Authentication failed!";

   4:      private IMembershipService _membershipService;

   5:      private INavigationService _navigationService;

   6:   

   7:      public LoginForm()

   8:      {

   9:          InitializeComponent();

  10:          _membershipService = new MembershipService();

  11:          _navigationService = new NavigationService(this);

  12:      }

  13:   

  14:      public LoginForm(

  15:          IMembershipService membershipService, 

  16:          INavigationService navigationService

  17:          )  //This constructor is only for testing purposes

  18:      {

  19:          _membershipService = membershipService;

  20:          _navigationService = navigationService;

  21:      }

  22:   

  23:      public void LoginButton_Click(object sender, EventArgs e)

  24:      {

  25:          if (_membershipService.Authenticate(

  26:              UserNameText.Text, 

  27:              PasswordText.Text)

  28:             )

  29:          {

  30:              _navigationService.NavigateTo(new MainForm());

  31:          }

  32:          else

  33:          {

  34:              MessageLabel.Text = AUTHENTICATION_FAILED; 

  35:          }

  36:      }

  37:  }

  38:   

  39:  public interface INavigationService

  40:  {

  41:      void NavigateTo(Form focusForm);

  42:  }

  43:   

  44:  public class NavigationService : INavigationService

  45:  {

  46:      private Form _form;

  47:      public NavigationService(Form form)

  48:      {

  49:          _form = form;

  50:      }

  51:   

  52:      public void NavigateTo(Form focusForm)

  53:      {

  54:          _form.Hide();

  55:          focusForm.Show();

  56:      }

  57:  }

Here we encapsulated the Navigation logic into a Service and we’ve created a specific constructor that can be used by our tests to inject a test double making possible to write the following test:

   1:  [Test]

   2:  public void LoginButton_Click_OnSuccessfullLogin_ShouldNavigateToMainForm()

   3:  {

   4:      //Arrange

   5:      var mocks = new MockRepository();

   6:      var membershipServiceMock = mocks.StrictMock<IMembershipService>();

   7:      var navigationServiceMock = mocks.StrictMock<INavigationService>();

   8:      var form = new LoginForm(membershipServiceMock,navigationServiceMock);

   9:   

  10:      Expect.Call(membershipServiceMock.Authenticate(null, null)).Return(true);

  11:      navigationServiceMock.NavigateTo(null);

  12:      LastCall.IgnoreArguments();

  13:      mocks.ReplayAll();

  14:   

  15:      //Act

  16:      form.LoginButton_Click(null,null);

  17:   

  18:      //Assert

  19:      mocks.VerifyAll();

  20:  }

By applying one of the variants of the MVC pattern namely the PresentationModel we can completely decouple the presentation logic from infrastructure and test it in isolation:

   1:  public interface ILoginFormView

   2:  {

   3:      string UserName { get; set; }

   4:      string Password { get; set; }

   5:      string Message { get; set; }

   6:   

   7:      void NavigateTo(Form focusForm);

   8:  }

   9:   

  10:  public interface IMembershipService

  11:  {

  12:      bool Authenticate(string userName, string password);

  13:  }

  14:   

  15:  public class LoginFormPresenter

  16:  {

  17:      const string AuthneticationFailedMessage = "Authentication failed!";

  18:      private readonly ILoginFormView _view;

  19:      private readonly IMembershipService _membershipService;

  20:   

  21:      public LoginFormPresenter(ILoginFormView view, IMembershipService membershipService)

  22:      {

  23:          _view = view;

  24:          _membershipService = membershipService;

  25:      }

  26:   

  27:      public void LoginButtonClick()

  28:      {

  29:   

  30:          if (_membershipService.Authenticate(

  31:                      _view.UserName,

  32:                      _view.Password

  33:                      )

  34:              )

  35:          {

  36:              _view.NavigateTo(new MainForm());

  37:          }

  38:          else

  39:          {

  40:              _view.Message = AuthneticationFailedMessage;

  41:          }

  42:      }

  43:   

  44:  }

  45:   

  46:  public partial class LoginForm : Form, ILoginFormView 

  47:  {

  48:      private LoginFormPresenter _presenter;

  49:   

  50:      public string UserName

  51:      {

  52:          get

  53:          {

  54:              return UserNameTextBox.Text;

  55:          }

  56:          set

  57:          {

  58:              UserNameTextBox.Text = value;

  59:          }

  60:      }

  61:   

  62:      public string Password

  63:      {

  64:          get

  65:          {

  66:              return PasswordTextBox.Text;

  67:          }

  68:          set

  69:          {

  70:              PasswordTextBox.Text = value;

  71:          }

  72:      }

  73:   

  74:      public string Message

  75:      {

  76:          get

  77:          {

  78:              return MessageLabel.Text;

  79:          }

  80:          set

  81:          {

  82:              MessageLabel.Text = value;

  83:          }

  84:      }

  85:   

  86:      public LoginForm()

  87:      {

  88:          InitializeComponent();

  89:          _presenter = new LoginFormPresenter(this, new MembershipService());

  90:      }

  91:   

  92:      public void LoginButton_Click(object sender, EventArgs e)

  93:      {

  94:         _presenter.LoginButtonClick();

  95:      }

  96:   

  97:      public void NavigateTo(Form focussedForm)

  98:      {

  99:          Hide();

 100:          focussedForm.Show();

 101:      }

 102:  }

We are now able to test the presentation logic:

   1:  [TestFixture]

   2:  public class LoginFormPresenterTest

   3:  {

   4:      const string UserName = "myUserName";

   5:      const string Password = "myPassword";

   6:   

   7:      [Test]

   8:      public void LoginButtonClick_AuthenticationSuccess_ViewShouldNavigateToMainForm()

   9:      {

  10:          //Arrange

  11:          var viewMock = CreateLoginFormViewStub();

  12:          var membershipServiceMock = CreateMembershipServiceMock(true);

  13:          var subject = new LoginFormPresenter(viewMock, membershipServiceMock);

  14:   

  15:          //Act

  16:          subject.LoginButtonClick();

  17:   

  18:          //Assert

  19:          viewMock.AssertWasCalled(

  20:              s => s.NavigateTo(null),

  21:              options => options.IgnoreArguments()

  22:              );

  23:      }

  24:   

  25:      [Test]

  26:      public void LoginButtonClick_AuthenticationFailed_ViewMessageIsAuthenticationfailed()

  27:      {

  28:          //Arrange

  29:          var viewMock = CreateLoginFormViewStub();

  30:          var membershipServiceMock = CreateMembershipServiceMock(false);

  31:          var subject = new LoginFormPresenter(

  32:                            viewMock,

  33:                            membershipServiceMock

  34:                            );

  35:   

  36:          //Act

  37:          subject.LoginButtonClick();

  38:   

  39:          //Assert

  40:          Assert.AreEqual("Authentication failed!", viewMock.Message);

  41:      }

  42:   

  43:      private IMembershipService CreateMembershipServiceMock(bool expectedResult)

  44:      {

  45:          var membershipServiceMock = MockRepository.GenerateStub<IMembershipService>();

  46:          membershipServiceMock.Stub(m => m.Authenticate(UserName, Password)).Return(expectedResult);

  47:          return membershipServiceMock;

  48:      }

  49:   

  50:      private ILoginFormView CreateLoginFormViewStub()

  51:      {

  52:          var viewMock = MockRepository.GenerateStub<ILoginFormView>();

  53:          viewMock.UserName = UserName;

  54:          viewMock.Password = Password;

  55:          return viewMock;

  56:      }

  57:  }

When designing UI’s you should make your choice between patterns like MVC/MVP/MVVM and use the most appropriate pattern and/or framework for your project.  With the appropriate design a lot of the presentation logic encapsulated into the UI can be extracted and tested. In this example we extracted all the presentation logic encapsulated in our form and transferred it into a presenter. This presenter is completely decoupled from any infrastructure and we are able to easily obtain 100% test coverage with it. The LoginForm itself remains un-testable but it does not contain any logic anymore. His only purpose is to act as a sort of proxy between the windows forms infrastructure and our presentation logic.

Let’s imagine we want to add caching capabilities for our InvoiceRepository class.

public class InvoiceRepository

{

    private IDataLayer _db;

    public InvoiceRepository(IDataLayer db)

    {

        _db = db;

    }

    public Invoice GetInvoice(int clientID)

    {

        Cache cache = Cache.GetInstance();

        string key = "Invoice" + clientID.ToString();

        if (cache[key]==null)

        {

            MeteringValues[] dailyValues = _db.GetMeteringValues(clientID);

            int offPeakPrice = _db.GetOffPeakPrice();

            int peakPrice = _db.GetPeakPrice();

            int advances = _db.GetAdvances(clientID);

            cache.Add(key, new Invoice(dailyValues, offPeakPrice, peakPrice, advances));

        }

        return (Invoice)cache[key];

    }

}

In this example we reach into the global state of our InvoiceRepository class and get a hold of the Cache singleton (Cache.GetInstance()). Global variables often show up as instances of the singleton pattern or just as static data in classes.

Not all singletons are bad design but all of them are suspect, presumed guilty until proven innocent! Nevertheless singletons which do not affect the functional behaviour of an application, can behave well as internal dependencies. A good example is the use of the singleton pattern for caching. Using the singleton pattern to implement caching is a valid strategy. The example here above illustrate this strategy nevertheless this example has a big flaw! The flaw is that we can’t intercept the call Cache.GetInstance. We can’t use a mocking framework to replace the Cache.GetInstance as this is a static method and static methods can’t be mocked (with Rhino Mock).

To solve this issue we need to extract the global state out of our Domain Object. We could for example pass a “Cache” object into the constructor:

public InvoiceRepository(IDataLayer db, ICache cache)

But imagine what would happen if we also want to log our exceptions and operations this would result in the following signature:

public InvoiceRepository(IDataLayer db, ICache cache, ILogger log)

When using the dependancy injection pattern (through constructor injection) every dependency to a service will result in a parameter we need to pass in our constructor.  That's why when we have a lot of dependencies (and usually we do)  using denpendancy injection result in classes that are difficult to instantiate because we need to inject all  cross cutting concerns (the cache, the logger, …) via the constructor. To solve this issue we can use the factory pattern. Nevertheless the Factory itself is still in his own way making our code more complex. This is why most of Unit test addicts advocates the use of IOC containers like Structuremap or Unity. 

Using an IOC container our code would look like this:

public class InvoiceRepository

{

    private IDataLayer _db;

    private ICache _cache;

    public InvoiceRepository()

    {

        _db = ObjectFactory.GetInstance<IDataLayer>();;

        _cache = ObjectFactory.GetInstance<ICache>();

    }

…

}

To test our SUT we can easily configure our container during the Arrange part of our unit test and don’t need to pass these dependencies through the constructor:

//Arrange

myIOCContainer.ForRequestedType<ICache>.TheDefaultIs<StubedCache>();

I plan to write some articles regarding how to write good unit tests but before providing what my guidelines are regarding unit testing it’s important to first understand what are the reasons why we want to unit test and what are the drivers for depicting these guidelines. Because my objective is to encourage developers to practice unit testing, I choose to address the main oppositions I encounter today on the field.

Unit testing is not productive!

If we take a closer look to how productivity is optimized in classical manufacturing process, we can envision why well written, well maintained unit tests have exactly the opposite effect.

The productivity of a factory is measured by the speed at which products flaws from the production line and the effectiveness of the production line. As one may think, the speed at which products flaws out of the factory is not the average speed of each part of the production line but it depend mostly on of the number of things to process in the production line. So if you want to increase the overall production capacity of a factory you’ve to synchronize every part of the production line and make sure that each part works at a constant peace and that every part is working at a sustainable piece for him and his neighbor. The worsted thing that can happen in a production line is that a defect is caused in a part of the line and is paced at the next part. The defect will not only cause the part of the line where the defect is detected to stop but the defect part has also to be resent to the part of the line where the defect was made. This will desynchronize the overall production line and diminish the overall productivity of the factory. When we produce software the same is true, if a bug is detected by the testing team or worse in production it will generate a lot of waste. The bug will need to be described precisely; the developers will need to switch from their ongoing task to the bug resolution. A lot of time will be loosed in understanding the problem. The bug resolution will need to be tested. Finally a patch will need to be deployed in production potentially causing a service interruption. There is also a consequent risk to repeat this process the defect was not corrected adequately or because a new defect is caused by the resolution. An important side effect for unit test is also that they reduce the risk of a project. Each unit test is an insurance that the system works. Having a bug in the code means carrying a risk. Utilizing a set of unit tests, engineers can dramatically reduce number of bugs and the risk with untested code.

Unit tests will also decrease the maintenance cost because they provide a living documentation. This is called "Test as documentation". Unit testing provides a sort of living documentation of the system. Developers looking to learn what functionality is provided by a unit and how to use it can look at the unit tests to gain a basic understanding of the unit.  Unit tests embody characteristics that are critical to the success of the unit. These characteristics can indicate appropriate/inappropriate use of a unit as well as negative behaviors that are to be trapped by the unit. A unit test case documents these critical characteristics.

So it’s true that unit tests are generally doubling the initial cost of the implementation phase because it tends to cost the same amount of time as writing production code. But this cost is more than re-gain because the other steps of the production process shorten. The amount of defects detected by the Q&A team is drastically falling and a lot of time is won because the Q&A team can work faster. Even the overall throughout put of the development teams increases at the end because a time is not loosed anymore in correcting a lot of defects detected by the Q&A team. The project manager is far better at estimated the project status. At the end the trust of the business increases because they get features build on a constant pace and because the overall delivered quality increases.

Unit testing does not catch all bugs!

Unit testing and other forms of automated testing serve the same purpose as the automated testing devices in manufacturing. Unit tests will enable to detect rapidly a defect when code is changed or added. The automated tests are not made to detect malfunctions in production but to prevent that defects could enter into our assembly line.  The real value of Unit testing & TDD is not that they can detect defects but that they overcome defects to happen!  Unit testing will not only improve the quality perceived by the business because lesser defects will slip through it will also improve the internal quality attributes of the code itself because the developer will tend to refactor a lot more and will design his code more loosely coupled. (see Design for testability). 

Nevertheless Unit testing alone is not sufficient, testing should happen on all levels but unit tests decrease the amount of other kind of testing that is needed. Because unit testing helps to eliminate uncertainty in the units themselves they enable a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

Testing is for the testers!

Unit testing and other forms of automated testing serve the same purpose as the automated testing devices in manufacturing. Unit tests will enable to detect rapidly a defect when code is changed or added. The automated tests are not made to detect malfunctions in production but to prevent that defects could enter into our assembly line. The real value of Unit testing & TDD is not that they can detect defects but that they overcome defects to happen! Unit testing will not only improve the quality perceived by the business because lesser defects will slip through it will also improve the internal quality attributes of the code itself because the developer will tend to refactor a lot more and will design his code more loosely coupled.

When software is developed using a test-driven approach, the Unit-Test may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior. By writing your tests you are performing an act of design and all professional developers should aim for good design.

Unit testing is a waste of time because they tend to break and we constantly have to fix them!

Unit testing allows the programmer to refactor code at a later date, and make sure the module still works correctly. The unit tests enables refactoring because they provide a safety net that allows us to practice refactoring. The procedure is to write test cases for all methods so that whenever a change causes a fault, it can be quickly identified and fixed. Readily-available unit tests make it easy for the programmer to check whether a piece of code is still working properly. They enable us to constantly improve our SUT by adhering to the DRY principles. This principle does not only apply to our SUT but also to our test code. By constantly keeping our testsDRY by eliminating duplication we improve the maintainability of our tests and make sure that these tests stay efficient. When you spent too much time in fixing tests you should consider to review your test design. Have a look at the following articles these will provide some guidelines that will help you in increasing the maintainability of your tests.

This code is too difficult to test! 

Because unit tests forces us to exercise our code in another context as the context in which the code will run in production – the tests forces us to design our code so that it is more loosely coupled. Loose coupling tend to improve reusability and robustness. Reusability and robustness are certainly desirable goals. So Unit testing is a way to assert that our code is robust and reusable – if your code is hard to test this is mostly because there is something wrong with your design and you should not try to test bad design but you should fix it!