Prism Walkthrough - Part 3: Add Views to Regions

Source code of this part can be downloaded here.

In this part we’ll create our first views and display them inside their regions.  The views are the controls that display our content.  Because our application is build with modularity in mind it’s the Module and not the Shell that should define which views need to be added to the regions. 



1) We add a folder “Views” to our Module project and 4 views inside this new folder: 

  • CreateFileView:  One of the views that can be displayed in the MainRegion
  • CreatFolderView: Another view for the MainRegion
  • MenuView: Control that will be responsible to Add views to the MainRegion
  • StatusBar: Control that will be added to the StatusBarRegion



To add views to our regions we use the prism region manager service.  The region manager service is responsible for maintaining a collection of regions and creating new regions for controls.  Typically, we interact directly with region manager service to locate regions in a decoupled way through their name and add views to those regions. By default, the UnityBootstrapper base class registers an instance of this service in the application container. This means that we can obtain a reference to the region manager service in our application by using dependency injection.

We use constructor dependency injection to gather an instance of the RegionManager and store it in a local field and it’s  in the Initialize method of our CoreModule class that we implement logic to add the initial views to our Regions. 


2) Modify the CoreModule class like:

   1:  public class CoreModule : IModule
   2:  {
   3:      private readonly IRegionManager regionManager;
   5:      public CoreModule(IRegionManager regionManager)
   6:      {
   7:          this.regionManager = regionManager;
   8:      }
  10:      public void Initialize()
  11:      {
  12:          this.RegisterViewsWithRegions();
  13:      }
  15:      protected virtual void RegisterViewsWithRegions()
  16:      {
  17:          this.regionManager.RegisterViewWithRegion(RegionNames.MenuRegion, typeof(MenuView));
  18:          this.regionManager.RegisterViewWithRegion(RegionNames.StatusbarRegion, typeof(StatusbarView));
  19:      }
  20:  }



To overcome magic constants in our code  we used a class containing all our region names.


3) Add this RegionNames class to your Infrastructure Library:

   1:  namespace PrismWalkthrough.Infrastructure
   2:  {
   3:      public class RegionNames
   4:      {
   5:          public const string MainRegion = "MainRegion";
   6:          public const string MenuRegion = "MenuRegion";
   7:          public const string StatusbarRegion = "StatusbarRegion";
   8:      }
   9:  }



Finally to see something displayed in our Menu and StatusBar we need to add some content inside these controls:


4) Modify the MenuView.xaml:

    <Menu Name="menu1" Background="Transparent" >
        <MenuItem Header="File" >
            <MenuItem Header="New"  CommandParameter="CreateFile" />
            <MenuItem Header="Folder" CommandParameter="CreateFolder"  />


5) Modify the StatusBarView.xaml:

    <TextBlock Text="This is the StatusBar" />


When pressing F5 you should see:



kick it on

Prism Walkthrough - Part 2: Define The Regions

Define the Regions


Our shell will contain 3 regions:

  • Menu Region: contain a Menu that is responsible to load views in the Main Region
  • Main Region: region that will load the workspace controls – these are the views that will handle the application features. In our application only one view at a time can be loaded in the Main Region.
  • Status Bar Region: provide info about current application state 


These regions are the placeholders for the controls defined in our Modules.  Our application will contain only one Module: the CoreModule but this application can easily be extended by adding new modules.   In our application the regions are defined as ItemsControls  in the Shell.xaml file and can be accessed in a decoupled way by their names; they support dynamically adding or removing views at run time.

  1. To add the regions in the Shell window add the following namespace definition to the root Window element. You need this namespace to use an attached property for regions that is defined in the Composite Application Library:  xmlns:cal=
  2. Replace the Grid in the Shell by the following xaml:
            <RowDefinition Height="35" />
            <RowDefinition Height="*" />
            <RowDefinition Height="35" />
        <ItemsControl Name="MenuRegion" cal:RegionManager.RegionName="MenuRegion" 
    VerticalAlignment="Top" Grid.RowSpan="2" Height="26" HorizontalAlignment="Left" Background="Transparent" Margin="0,12,0,0"/>
    <Grid Margin="4,4,4,4" Grid.Row="1"> <Border Background="GhostWhite" BorderBrush="LightGray"
    BorderThickness="1" CornerRadius="5" Margin="0,0,0,0"> <ItemsControl Name="MainRegion"
    cal:RegionManager.RegionName="MainRegion" Margin="4" Height="291" />
    </Border> </Grid> <Border Grid.Row="2" > <ItemsControl Name="StatusbarRegion"
    cal:RegionManager.RegionName="StatusbarRegion" Background="Transparent" />
    </Border> </Grid>


Now you should be able to run the application and see this screen:



Next --->

kick it on





Prism walkthrough - Part 1: Create The Shell


The client side application is made out of three assemblies:

  • The Shell (PrismWalkthrough.Shell)
  • The Modules ( PrismWalkthrough.Modules)
  • The Infrastructure (PrismWalkthrough.Infrastructure)

The foundation of the application is “The Shell”.  The Shell is the top-level window of an application based on the Prism Composite Application Library. This window is a place to host different user interface (UI) components that exposes a way for itself to be dynamically populated by others, and it may also contain common UI elements, such as menus and toolbars. The Shell window sets the overall appearance of the application.


In our application it’s the shell that is responsible to load the Modules. A module represents a set of related concerns. It can include components such as views, business logic, and pieces of infrastructure, such as services for logging or authenticating users. Modules are independent of one another but can communicate with each other in a loosely coupled fashion.  In this walkthrough our application will contain only one module: the CoreModule nevertheless the modular architecture enable us to easily extend the application adding new modules later on.


The Infrastructure Assembly is a shared library referenced by both the shell project and the module projects, and holds shared types such as constants, event types, entity definitions and interfaces.


Create the Solution


  1. Create the Shell project (PrismWalkthrough.Shell) application with Visual Studio-> File, Project, WPF Application.
  2. Add the Modules project and Infrastructure project –> File, Add New Project, Classlibrary
  3. The three projects should reference the Composite Application Library assemblies, add the following reference:
    (These assemblies can be found in the october 2009 Guidance of Prism -  you will need to compile the sample application)
      • Microsoft.Practices.Composite.dll
      • Microsoft.Practices.Composite.Presentation.dll
      • Microsoft.Practices.Composite.UnityExtensions.dll
      • Microsoft.Practices.Unity.dll
      • Microsoft.Practices.ServiceLocation.dll
  4. Add a reference to the Modules and Shell projects referencing the Infrastructure assembly.
  5. Add a refrence to the Shell project referencing the Modules assembly.
  6. Add a refrence to the Modules and infrastructure that reference to the WindowsBase & PresentationCore and PresentationFramework –> Reference, Add, .Net tab.


Your solution should look like this:





Initialize the application

To enable modularity and dependency injection in our application we need to make some changes to the standard WPF application we just created.  First we setup a bootstrapper.  The bootstrapper is responsible for the initialization of the application, this is realized by overriding the CreateShell method.

  1. Add a new class on the root of the application containing the shell (PrismWalkthrough.Shell), name it Bootstrapper
  2. The Bootstrapper should inherit from Microsoft.Practices.Composite.UnityExtensions.UnityBootstrapper class and override the CreateShell method. You need to instantiate the Shell through the Unity conatiner and call his Show method
   1:  public class Bootstrapper : UnityBootstrapper
   2:  {
   3:      protected override System.Windows.DependencyObject CreateShell()
   4:      {
   5:          Shell shell = this.Container.Resolve<Shell>();
   6:          shell.Show();
   7:          return shell;
   8:      }
   9:  }


To be able to run the bootstrapper at least one module should be registered in our application. 

  1. Add a class to the PrismWalkthrough.Module and name it CoreModule.cs
  2. This class should implement the IModule interface:
   1:  namespace PrismWalkthrough.Modules
   2:  {
   3:      public class CoreModule : IModule
   4:      {
   5:          public void Initialize()
   6:          {
   8:          }
   9:      }
  10:  }


Through the bootstrapper you must configure which Modules are available in our Shell. You need to register at least one module in your bootstrapper.

  1. Override the InitializeModules in the bootstrapper:
   1:  protected override void  InitializeModules()
   2:  {
   3:      IModule coreModule = this.Container.Resolve<CoreModule>();
   4:      coreModule.Initialize();
   5:  }


The WPF Application class needs to execute the bootstrapper by calling his Run method. 

  1. First you should delete the StartupUri in the App.Xaml file.
    <Application x:Class="PrismWalkthrough.Shell.App"
  2. Override the OnStartup method in the App.cs file:
   1:  protected override void OnStartup(StartupEventArgs e)
   2:  {
   3:      base.OnStartup(e);
   4:      Bootstrapper bootstrapper = new Bootstrapper();
   5:      bootstrapper.Run();
   6:  }


Now you should be able to run you application, you should see a white screen.

Next --->


Create a refrence WPF application using MVVM with Prism, WCF and Entity Framework

In this series of posts I’ll build a reference WPF application(template) that can be used as a template for line of business applications (LOB). . This series will take the form of a walkthrough providing an introduction to the development of a Windows Presentation Foundation (WPF) application with Prism using the MVVM (Model View ViewModel) that includes the elements that are common to most WPF applications.


This walkthrough guides you through the development of a WPF/Prism desktop application using the following steps:


  • Defining the application architecture. 
  • Creating the Shell with his Regions Loading our Core Module.
  • Use styles to create a consistent appearance.
  • Use the Command pattern.
  • Using Unity as IOC.
  • Setting up the infrastructure for MVVM.
  • Use WCF to setup our Service Layer.
  • Use the Entity Framework as DAL.




Part 0: Defining the application architecture


This application will be build using a Rich Internet Application Architecture (RIA). This architecture type uses a Web infrastructure that combined with a client-side application that handles the presentation. The Web infrastructure will be build using WCF and the client-side application will be build with WPF.


The client side application will use Prism for extensibility and to get the basic infrastructure for applying MVVM pattern.   This application will be composed of the following components:


  • The shell: the main window that is responsible to load all other modules.
  • The core module: contains the basic components to enable the basic functionalities of the application.

By dividing our client application in these two components we make our application ready to be extended; we will be able to add new features without touching to the code of the core module.

The WCF application is composed of several layers:

  • The service layer containing the message types.
  • The business layer contains business logic.
  • The data layer contains data access components.


The data layer will use the Entity Framework 2.0 to interact with the DB.


To be continued --->

kick it on

Anti-Pattern 5: Fat UI's

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:      }
   9:      private void LoginButton_Click(object sender, EventArgs e)
  10:      {
  11:          var membershipService = new MembershipService();
  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;
   7:      public LoginForm()
   8:      {
   9:          InitializeComponent();
  10:          _membershipService = new MembershipService();
  11:          _navigationService = new NavigationService(this);
  12:      }
  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:      }
  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:  }
  39:  public interface INavigationService
  40:  {
  41:      void NavigateTo(Form focusForm);
  42:  }
  44:  public class NavigationService : INavigationService
  45:  {
  46:      private Form _form;
  47:      public NavigationService(Form form)
  48:      {
  49:          _form = form;
  50:      }
  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);
  10:      Expect.Call(membershipServiceMock.Authenticate(null, null)).Return(true);
  11:      navigationServiceMock.NavigateTo(null);
  12:      LastCall.IgnoreArguments();
  13:      mocks.ReplayAll();
  15:      //Act
  16:      form.LoginButton_Click(null,null);
  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; }
   7:      void NavigateTo(Form focusForm);
   8:  }
  10:  public interface IMembershipService
  11:  {
  12:      bool Authenticate(string userName, string password);
  13:  }
  15:  public class LoginFormPresenter
  16:  {
  17:      const string AuthneticationFailedMessage = "Authentication failed!";
  18:      private readonly ILoginFormView _view;
  19:      private readonly IMembershipService _membershipService;
  21:      public LoginFormPresenter(ILoginFormView view, IMembershipService membershipService)
  22:      {
  23:          _view = view;
  24:          _membershipService = membershipService;
  25:      }
  27:      public void LoginButtonClick()
  28:      {
  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:      }
  44:  }
  46:  public partial class LoginForm : Form, ILoginFormView 
  47:  {
  48:      private LoginFormPresenter _presenter;
  50:      public string UserName
  51:      {
  52:          get
  53:          {
  54:              return UserNameTextBox.Text;
  55:          }
  56:          set
  57:          {
  58:              UserNameTextBox.Text = value;
  59:          }
  60:      }
  62:      public string Password
  63:      {
  64:          get
  65:          {
  66:              return PasswordTextBox.Text;
  67:          }
  68:          set
  69:          {
  70:              PasswordTextBox.Text = value;
  71:          }
  72:      }
  74:      public string Message
  75:      {
  76:          get
  77:          {
  78:              return MessageLabel.Text;
  79:          }
  80:          set
  81:          {
  82:              MessageLabel.Text = value;
  83:          }
  84:      }
  86:      public LoginForm()
  87:      {
  88:          InitializeComponent();
  89:          _presenter = new LoginFormPresenter(this, new MembershipService());
  90:      }
  92:      public void LoginButton_Click(object sender, EventArgs e)
  93:      {
  94:         _presenter.LoginButtonClick();
  95:      }
  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";
   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);
  15:          //Act
  16:          subject.LoginButtonClick();
  18:          //Assert
  19:          viewMock.AssertWasCalled(
  20:              s => s.NavigateTo(null),
  21:              options => options.IgnoreArguments()
  22:              );
  23:      }
  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:                            );
  36:          //Act
  37:          subject.LoginButtonClick();
  39:          //Assert
  40:          Assert.AreEqual("Authentication failed!", viewMock.Message);
  41:      }
  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:      }
  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.


kick it on

Anti-Pattern 4: Using Global State

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:


kick it on

Anti-Pattern 3: Overloaded Constructor

In the previous example the “Invoice” object is responsible to retrieve all the values needed to calculate the balance and it also contains the business logic that performs the calculation. This violates the SRP (Single Responsibility Principle). Because of this flaw when we test the calculation of the Balance we need to inject a test double so that the invoice can retrieve values. Why should we need to pass a Service when the only thing our Invoice should be responsible for is the calculation of the Balance?

In the code example here below we specialized the Invoice class. Only what is directly needed is passed in: the input data to calculate the balance. To adhere to the SRP we extract the logic that retrieves the data from our DataLayer out of the Invoice class and create a Repository class (see Repository pattern). We don’t need any mock object anymore what enhance the readability and robustness of our test. By adhering to the SRP we improve our design and enable for better testability.


public class Invoice
    private int _balance;
    public Invoice(MeteringValues[] dailyValues, int offPeakPrice, int peakPrice, int advances)
        int peakConsumption = CalculatePeakConsumtion(dailyValues);
        int offPeakConsumtion = CalculateOffPeakConsumtion(dailyValues);
        _balance = CalculateBalance(
public class InvoiceRepository
    private IDataLayer _db;
    public InvoiceRepository(IDataLayer db)
        _db = db;
    public Invoice GetInvoice(int clientID)
        MeteringValues[] dailyValues = _db.GetMeteringValues(clientID);
        int offPeakPrice = _db.GetOffPeakPrice();
        int peakPrice = _db.GetPeakPrice();
        int advances = _db.GetAdvances(clientID);
        return new Invoice(dailyValues, offPeakPrice, peakPrice, advances);


Anti-Pattern2: Coupling between Domain & Infrastructure

In the previous example we’ve extracted all the infrastructure code from the Invoice class and created a new class: the DataLayer. Nevertheless the Invoice class is now strongly coupled to the DataLayer class. To decouple these two classes we can make use of interfaces:

  2: {
  3:         private int _balance;
  5:         public Invoice(int clientID, IDataLayer db){
  6:           … 
  7:         }
  8:         …
  9: }

The interface IDataLayer is a sort of wrapper around the infrastructure code – this interface defines a contract for our infrastructure code, this type of interface is sometimes called a service interface. By creating this service interface we decouple the infrastructure from the domain logic as it does not depend on any concrete implementation anymore. The same strategy can be applied when working with hard to test third party code like the VSTO object model. By creating an interface that defines a façade around the third party component we make sure our SUT is testable and decouple our domain logic from the infrastructure code.

We can use unit tests and the test doubles for designing the service interface that your code depends on. To design this service interface we could take some inspiration from the TDD process. For each new feature we write a unit test that uses a test double to simulate the behavior that your target object needs from its environment; each test double is a hypothesis of what the real code will eventually do. This interface can then be used via Mocking frameworks to generate test doubles. As the cluster of a service interfaces and its test doubles stabilises, we can then begin to wire up your own Service classes with the underlying 3rd party API. The untested code would then be contained into these service classes and will not propagate into your domain code (Entities & Value objects). You would then obtain a clean and homogenous API that was dictated by what your own domain classes needs.


Design For Testability

Design for testability


How can we recognize “Bad Design”? One could argue that a design can be qualified as “Bad” when it can’t be changed easily. When one small change in the code implies to make a lot of other changes or when the program break in many places when a single change is introduced. Because the parts are highly dependent on each other no effort will be invested in separating the modules that can be reused. Therefore a badly designed application will also tend to not be reused. The root of these symptoms is caused by the interdependencies between the building blocks of the application. The art of good design is to break these dependencies.


An interesting fact is that code that is interdependent is also difficult to test. That’s why our unit test are the most effective way to evaluate our design. Well designed applications made of loosely coupled parts will be easy to unit test. The opposite is also true, code that is easy to unit test is code that is generally well designed.  Unit testing is not about detecting existing defects but it’s an act of design. Unit tests help us in defining and evaluate our design. A piece of code that is difficult to test is a smell of bad design. When our code is difficult to test we should not try to write a test for it, we should first change it so it can be easily tested.

“If the answer is not obvious, or it looks like the test would be ugly or hard to write, then take that as a warning signal. Your design probably needs to be modified; change things around until the code is easy to test, and your design will end up being far better for the effort.” [Hunt, Thomas. Pragmatic Unit Testing in Java with JUnit.

In this series I describe what make our code hard to test therefore I provide several typical design anti-patterns  that makes our code hard to test and explain how these can be fixed. I provide also some patterns that can be applied in our SUT that can facilitate testing and enforce loose coupling.




1) The new keyword is used to construct anything you could replace with a test-double.

The most common cause making our test hard to test is violating the single responsibility principle. Look at the example here beneath, the SUT is responsible to construct his own collaborators. When your class has to instantiate and initialize its collaborators, the result tends to be an inflexible and prematurely coupled design. Such classes shut off the ability to inject test collaborators when testing. Do not create collaborators in your constructor or methods, but pass them in. (Don’t look for things! Ask for things!)

   1:  public class Invoice
   2:  {
   3:      private int _balance;
   5:      public Invoice(int clientID)
   6:      {
   7:          DataLayer _db = new DataLayer();
   9:          MeteringValues[] dailyValues = _db.GetMeteringValues(clientID);
  10:          int offPeakPrice = _db.GetOffPeakPrice();
  11:          int peakPrice = _db.GetPeakPrice();
  12:          int peakConsumption = CalculatePeakConsumtion(dailyValues);
  13:          int offPeakConsumtion = CalculateOffPeakConsumtion(dailyValues);
  14:          int advances = _db.GetAdvances(clientID);
  16:          _balance = (peakConsumption * peakPrice +   
  17:                      offPeakConsumtion * offPeakPrice) – 
  18:                      advances;
  19:      }
  21:      public int Balance
  22:      {
  23:          get { return _balance; }
  24:      }  
  26:      private int CalculateOffPeakConsumtion(MeteringValues[] values)
  27:      {
  29:      }
  31:      private int CalculatePeakConsumtion(MeteringValues[] values)
  32:      {
  34:      }
  35:  }


In the example here above, we can never replace the _db field with a test-double.  It’s true that the Invoice is easy to instantiate but this come at the cost of flexibility.  Because the DataLayer represents something expensive to access it is also not very testable .  To be able to inject a stubbed DataLayer into the Invoice we add a dataLayer parameter to the constructor:

   1:  public class Invoice
   2:      {
   3:          private int _balance;
   5:          public Invoice(int clientID, DataLayer db)
   6:          {
   7:              MeteringValues[] dailyValues = db.GetMeteringValues(clientID);
   8:              int offPeakPrice = db.GetOffPeakPrice();
   9:              int peakPrice = db.GetPeakPrice();
  10:              int peakConsumption = CalculatePeakConsumtion(dailyValues);
  11:              int offPeakConsumtion = CalculateOffPeakConsumtion(dailyValues);
  12:              int advances = db.GetAdvances(clientID);
  14:              _balance = CalculateBalance(
  15:                              peakConsumption, 
  16:                              peakPrice,  
  17:                              offPeakConsumtion, 
  18:                              offPeakPrice, 
  19:                              advances
  20:                         );
  21:          }
  23:          protected int CalculateBalance(int peakConsumption, int peakPrice, int offPeakConsumtion, int offPeakPrice, int advances)
  24:          {
  25:              return (peakConsumption * peakPrice + 
  26:                      offPeakConsumtion * offPeakPrice) – 
  27:                      advances;
  28:          }
  30:          protected int CalculateOffPeakConsumtion(MeteringValues[] values)
  31:          {
  33:          }
  35:          protected int CalculatePeakConsumtion(MeteringValues[] values)
  36:          {
  38:          }
  40:          public int Balance
  41:          {
  42:              get { return _balance; }
  43:          }
  44:      }


Here we dispose of a SUT that is a lot more testable because we are now able to inject a test doubles into the Invoice .  These test doubles can simply be a subtype based on DataLayer that returns default hard coded values.  A more advance technique is making use of a mocking framework to generate a stub/mock from the DataLayer class ->



  1: public void Construct_WithSampleValues_BalanceEqualsSampleBalance()
  2: {
  3:     //Arrange
  4:     var dalStub = MockRepository.GenerateStub<DataLayer>();
  5:     dalStub.Stub(m => m.GetMeteringValues(SampleClientID)).Return(SampleMeteringValues);
  6:     dalStub.Stub(m => m.GetOffPeakPrice()).Return(SampleOffPeakPrice);
  7:     dalStub.Stub(m => m.GetPeakPrice()).Return(SamplePeakPrice);
  8:     dalStub.Stub(m => m.GetAdvances(SampleClientID)).Return(SampleAdvances);
 10:     //Act
 11:     var subject = new Invoice(1, dalStub);
 13:     //Assert
 15:     Assert.AreEqual(SampleBalance, subject.Balance);
 16: }