Ok, this one will is going to sound a little odd but bare with me. The other day I received a call from a friend who I used to work with. He’s now moved on to a new company and is responsible for managing a team of developers who have been focused on developing internal systems.  

Upon starting with the company, the IT director had expressed his concerns that the development teams were generally gun ho about configuration management and that on many occasions critical systems had been down for extended periods. Basically, my friends role is to get a grip with these kind of issues and improve the overall quality and professionalism of the team.

He told me that the systems had been written in .net 1.1 and very little progress had been in terms of migrating them to 2.0 and definately no 3.5. Another key issue he had identified was that the application had absolutely no code coverage and therefore developers were unaware of what impact their changes could have to the behaviour of the applications. I think more to the point, as we discussed the environment, it became apparent that the majority of developers had very little understanding TDD and the benefits it can bring to your project.  

Given the environment, my friend and I discussed a number of options that he could take forward in terms of educating the team in the ways of TDD and primarily some way of obtaining some level of test coverage of the application code. It was the later thread that sparked an interesting conversation about conceptualising a test and how you can get increase coverage from a small number of tests. He had explained that the architecture was fairly standard with a complex model that uses fine-grained interfaces for business entities wrapped up with a coarse-grained interface that is exposed to the UI.

Discussing the split between UI code and service/business code it seemed there was approximately 30/70 split. Therefore, we both felt the best place to start would be at the service contract layer. The service contract provides a single point of access into a complex system. This is a very key point, what it essentially means is that by using the service contract and multiple data scenarios we can cover large portions of code within the complex model. To help developers visualise this concept, we talked through a few analogies that would fit.  Below are 3 visualisations of this.

As you can see, each of these images can be used to visualise the many branches of code that could possibly be taken from the top down entry point. Exploring these different paths takes a multitude of data scenarios. Each data scenario being passed into the top level entry point results in decisions being made on that data at each possible branch. Therefore theoretically, albeit unlikely, you could write 1 test for an service contract method that could be re-run many many times with different inputs and attain 100% coverage of the branches below.   Validating key state data on exit of these test runs can help enforce the behaviour of the system and identify issues that may arise from developers not being able to see the impact of their changes.  Its not ideal, but it is an option.

Human’s by nature react well to the visualisation of abstract concepts, it helps us comprehend complex intangible systems that other species have (so far) failed to master. They say a picture says a thousand words, I am thinking it could be a lot more.

In the case of the applications my friend needs to maintain, where no tests currently exist, this approach provides a valuable step in the right direction. It helps educate the developers who have not had to worry about testing before, as well as the additional advantage of  moving towards building important quality checks within the applications.  I am planning to catch up with my friend for beers in a few weeks time so I will update you to see how he is getting on.