Designing for Testability

For each piece of coded logic in the system, a unit test can be written easily enough to verify it works according to the PC-COF. The PC-COF are characteristics that must be true of the tests. They are as follows:
Partial test runs are possible.
Configuration not needed to run tests.
Test fails / passed Consistently.
Order in which test run does not affect the results.
Tests run Fast

Then we were shown the main ideas behind this is to use ‘Dependency Injection’ (also see Wiki on DI and MSMagazine). DI is about, instead of a class creating its own dependencies, they are given to it (either through maybe a constructor, or via properties). This allows us to give a class ‘fake’ dependencies that will behave in a specific known way in order to test them. It also brings our designs closer to the S.O.L.I.D principles of object oriented design.

However, the problem with using DI, is that very soon you come across constructors that need to take very many parameters, and objects than need many lines of code just to construct them. Step in IOC Containers. IOC containers are like smart factories. They can be configured either via code or via configuration file to create instances of objects. Thus, even though constructors take many arguments, by using the IOC Container, object creation is simplified. I’m hoping to give you guys a demo off this when I’m back. There are a number of IOC Containers out there at the moment. The most popular is Castle.Windsor and Unity is from Microsoft’s Patterns and Practices.

So going back to testing, is our system is designed to use DI, we can inject fake implementations of each dependency of the class we are testing so as to test only that class.

A final few notes that were said:
It may often seem that testability clashed with encapsulation which we are traditionally told to practice in object oriented design
Tests show intent so we can use them as requirement

So that was the main part of that session. Just a quick note, the guy mentioned we should take a look at ‘TestDriven.NET’ which is a very usefull plugin for VS.NET as well as ReSharper.

Now this session was so another day I went to another session on the future of unit testing...