“Inversion of control” and “dependency injection” are the 2 terms you can research for more information on this topic. I am going to talk in layman terms, only, as to why I think software test automation developers (or all developers) should be aware of this techniques. It is another very useful tool for your toolbox.

My first experience with IOC and dependency injection was with java, using the Spring framework a while back. More recently I have used Spring.NET, the .NET version of Spring. I am currently using Spring.NET and Unity, although there are many flavours of IOC containers out there.

For those of you who don’t have a clue what I am talking about, imagine a washing machine and a dishwasher. They both do the same job, washing, but go about it in very different ways. Although the idea of a combo washer/dishwasher has been patented, it is highly likely that for the foreseeable future we require 2 machines. They even have very similar user instructions,

1. Load machine
2. Insert detergent
3. Select program
4. Press Start

Imagine that you indeed had 1 machine that was a washer / dishwasher combo. Imagine that the hardware for the machine was sufficient for all types of washing. Imagine the machine had a card slot that accepted a card that had the software to execute for the type of washing you wanted to do. You inserted the “Dishwasher” card into the slot and the machine washed dishes. You didn’t care how it worked or what was under the shell, you just washed clothes and dishes according to the card you put in the machine. In a years time a new card came out for your machine that allowed it to wash small pets; No more taking your Chihuahua to the grooming parlour once a month. Put the new card in the machine, pop your dog in and hey presto, your beautifully clean, although mentally scarred, best friend appears 30 minutes later. That is inversion of control. The machine supplies the rules of how to wash and any implementation that follows the machines rules may be implemented as a new “card”. You configure the machine (put the card in) and it goes off and gets the implementation to execute.

So IOC, in my mind, is the idea of decoupling rules from implementation. Dependency injection provides one way to enable this. Hopefully you can already see how this may be useful to you. Let me now give you a more concrete example.

In my series Create Test Automation Framework I show how to create an automated test framework from the ground up. Currently it uses QTP as the test tool, or “engine”. In a future series I am going to modify the test application I provided for the above series to allow users to run the same tests against different “engines”.

Say your company had API, UI and database tests. These tests may target the same functionality, but the type of testing is different for each.

If you adopted a test language for your company then you could use the same language to execute tests using different engines,

The above steps all use QTP (4th column). So all steps are executed as UI test steps. If you changed column 4 in step 2 and 3 to API then these steps would be run as API test steps. We use the same language, but our configuration (API, UI, DB) tells the application what “engine” to use. IOC and dependency injection make this easy.

There are various types of dependency injection and I tend to prefer interface injection. It lends itself very well to unit testing and mocks in particular.

So the test language defines the rules by way of providing interfaces. Each engine that comes along implements functionality according to the provided interfaces. This would also mean you are not tied to a specific implementation. If your company suddenly decided that QTP was no longer the UI tool of choice, you would create a new assembly with your newly adopted UI tool, update the configuration files to point to the new assembly and away you go.

Hopefully that's enough to illustrate that these techniques are worth knowing and can provide huge benefit to not only software development projects, but software test automation efforts as well.

If you use Visual Studio 2003, 2005, 2008 or 2010 then you have to use resharper. It’s my favourite plug-in. You can find out more about it here on Wikipedia. It does require a licence, but I think its worth it.

A quick summary from Wikipedia,

The following is an incomplete list of ReSharper features and feature groups:^[1]

• Over 750 on-the-fly code inspections that can be displayed as errors, warnings, suggestions, or hints^[2] (including compiler errors and warnings)
• 550 quick-fixes - automated corrections to resolve errors and optimize code
• Navigation and search: view file structure; search for any code symbol, type or file in solution; search for symbol usages; quick navigation to usage, declaration, implementation, inheritors, base types etc.
• Code Completion and Parameter Info that extends Visual Studio's built-in IntelliSense
• 35 solution-wide code refactorings
• Over 150 context actions - "local refactorings"
• Code generation: generate code from usage; generate common type members, including properties, constructors, interface implementation etc.
• Support for unit testing using NUnit and MSTest

There are personal and commercial reasons why I like it.

I love keeping up to date with the latest technology, .NET Framework updates and C# updates. This can be time-consuming and actually is quite hard to keep up with. Especially if you are committed to project work. So the refactoring help Resharper provides is great. You can write some code in the way that you normally would and Resharper will offer to re-factor it if required, using the latest techniques available. There are loads of examples on the net, so your favourite search engine will reveal many examples.

On a commercial level it is a perfect solution to enforcing code standards. Configure resharper to suit your teams coding standards. Your developers then load the standardised resharper configuration. They code away and resharper keeps them on track to make sure that they adhere to specified standards.

Note: I am not affiliated with Jetbrains and do not receive any money for affiliate links or advertising.

If you are following my Create Test Automation Framework series you will have downloaded and installed the Test Editor application. If not it can be downloaded from here

I have not yet supplied source code for this application and some users may want to look at the code, either out of curiosity or wanting to expand on the codebase for their own use. They would definitely not simply be wanting to copy and publish the code as their own work :)

So for those who are not already aware, let me introduce Reflector

It is a free download and it allows you look at the code for any given .net assembly. I encourage you to download it and use it to look at my Test Editor application. The important bit is that the code you will see is unlikely to be the code I wrote when developing the application. The C# compiler will have optimised my code.

It is a great way to understand what the compiler is doing and also to look at code for assemblies of interest to you.

Important: I have given express permission to dissemble my application, but that may not always be the case. Please check out the licence terms of any software you would like to dissemble before proceeding. If the licence prohibits it then it is illegal.