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: }


WCF4 error message: server did not provide a meaningful reply

When setting up a WCF service with .Net4 using WCF I encountered the following error when passing large object graphs:
“The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.”

Obviously this error was due to the very minimal default quotas defined by WCF – I thought  I just had to increase the values in the config file to solve my problem. So I immediately went to the app.config file but I was rather surprised discovering that the configuration file was empty.

When inspecting the new features of WCF4 I discovered that Microsoft has put efforts to make the overall WCF experience just as easy as ASMX (this is at least what they claim) . Therefore WCF4 comes with a new “default configuration” model. In my opinion this default configuration scheme only obfuscates the inherent complexity of WCF4 and result is just more confusion.

Of course now your config file is empty but this does not simplify its use because the standard binding & behaviors quota’s are still targeted to minimal values. As soon as you try to do some real work with WCF you will get the error message described here above. This is error message mostly mean that you’ve to increase some of the default configuration values.

Here is an article describing the new configuration model of WCF4:

This is the configuration (using very permissive values) I use when developing WCF3 (to be adapted when you go in production)


        <binding name="BasicHttpBinding_IGroupService" closeTimeout="00:01:00"
            openTimeout="00:01:00" receiveTimeout="00:30:00" sendTimeout="00:01:00"
            allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
            messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
          <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
              maxBytesPerRead="4096" maxNameTableCharCount="16384" />
          <security mode="None">
            <transport clientCredentialType="None" proxyCredentialType="None"
                realm="" />
            <message clientCredentialType="UserName" algorithmSuite="Default" />
        <behavior name="largeObjectGraphBehavior">
          <dataContractSerializer maxItemsInObjectGraph="214748364" />
      <endpoint address="http://localhost:1763/GroupService.svc" binding="basicHttpBinding"
          bindingConfiguration="BasicHttpBinding_IGroupService" contract="GroupService.IGroupService"
          name="BasicHttpBinding_IGroupService" behaviorConfiguration="largeObjectGraphBehavior" />


        <binding maxBufferSize="655360000" maxReceivedMessageSize="655360000" >
          <readerQuotas maxArrayLength="1000000" />
<!-- notice there’s no name attribute -->
          <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
          <serviceMetadata httpGetEnabled="true" />
          <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="true" />
                 maxItemsInObjectGraph="1000000" />

    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />

Why should we test?

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!


kick it on





How to distinguish an integration test from a unit test?



Although unit & integration tests serve different purposes, we’ve a tendency to confuse both types of testing. In fact most of the tests we write tend to be integration tests.  In my opinion the main reason why we confuse both is because we use the same test automation framework (e.g. NUnit) to write unit tests and integration tests. Nevertheless we should always separate our unit tests from our integration tests because Integration tests tend to be more fragile, slower and require more maintenance as unit tests.

As described in Wikipedia integration tests, test the integration between modules. Unit Tests targets atomic (indivisible) units/modules.  In my opion the notion of module is not enough to separate Unit from integration tests because a module is a subjective concept, it can be a applied for many things; a class, a Layer, a Component...  Therefore I prefer to make the distinction based on the fact that the test is dependent or not on some infrastructure.  When our tests are dependent on some infrastructure we can’t pretend anymore that our test is exercising a single module.  So as soon as our test is dependent on some sort of infrastructure like a DB, file, Web Service, COM component… it’s depend on at least two units (our code & the infrastructure) and it should be qualified as an Integration test.    



Keyboard support for Menu control Sylverlight 4


Today I tried to validate an  Architecture by creating a POC.  The architecture is an N-Tier using Silverlight for the client.  The customer as one particular request that, I thought, was reasonable: all actions – including menu navigation – has to be available through keyboard.  

When I tried Silverlight 4 I was surprised not to find any menu control so I downloaded several open source and commercial menu controls.  I was very disappointed, after having searched for a couple of hours I didn’t manage to find any control providing a decent keyboard support.  Most controls provides some basic support but not one control enabled to gain focus on the first item through the keyboard.  You are able to use the keyboard (arrow keys) but you need first to select the control with the mouse!  Not one control provided support for Keyboard shortcut. 

This is my shortlist of open source Sylverlight controls:

Codeproject free Menu :

Codeplex free Menu :


Cannot start Microsoft Office outlook. Cannot open the outlook window

It’s now the third time I experience the same problem, for a strange reason outlook refuse to start anymore and I get the following error message: “"Cannot start Microsoft Office outlook. Cannot open the outlook window". Because I don’t want to google for it anymore I decided to put the resolution on my blog so that I can find it later.  

The solution is simple run:  Outlook.exe /resetnavpane