Last week, I followed the training ‘Professionnal Scrum Developper’ with Richard Hundhausen.
He showed a feature of Visual Studio.Net that I had never use: The test impact analysis tool.

In a nutshell, this is a tool that analyses your last code changes, and will detect which unit tests has to be rerun to ensure you did not break anything important.

Sounds promising.
But wait… how does it work internally?
I guess it detects which components/classes you changed and, by a quick search in your tests , detect which one are linked.
However, the coupling is not always easy to find. Especially if you are working in decoupled layers and you extensively use Dependency Injection principle.

So , a proof of concept was needed here:

Issue: Can the Test impact analysis feature of VS.NET 2010 detect a change on components if they are ‘glued’ together at runtime by a dependency Injection container like Unity?.

Please find below, the VS.Net solution , a very simple solution testing this concept.

Point of focus: On the Business Layer, we have a Customer business component which use internally 2 components: IEmailSender and IFTPSender.

One of this component (IEmailSender) is provided by dependency injection by Unity, the other (IFTPSender) is internally constructed in the constructor.

On the Test layer, I have a unit test in (GivenAValidCustomerBusiness), which test a method name Confirm() on the CustomerBusiness object.

My theory was : The test impact analysis engine will detect changes made on FTPSender, and not the changes made on EmailSender, since this last one is injected at runtime by Unity, so it is much harder to discover the links between CustomerBusiness and EmailSender components.

Result: SURPRISE!

The test impact analysis seems to correctly detect that if I make a change at the EmailSender component, it is flagging the WhenConfirmingCustomer() test method as impacted!

Of course, changes maded to the FTPSender (coupled much tighter to the CustomerBusiness) is having the same behavior  (the opposite would have been a surprise).

Conclusion:

Code changes made to components injected at runtime are treated the same as direct coupling.
I tip my hat to the team who has programmed the Test Impact Analysis.

Good job!

Repro steps: Here are the repro steps, (for those interested to see it live!):

- Ensure Test Impact is enabled in your testconfig
- Make a change to the CustomerBusiness component. Build. Go to the Test Impact View. Changes are detected. A test has to be rerun.
- Make a change to the FTPSender component . Build. Go to the Test Impact View. Changes are detected. A test has to be rerun.
- Make a change to the EmailSender component . Build. Go to the Test Impact View. Changes are detected. A test has to be rerun.

Here is the sample solution: TestImpactAnalysis project