In my previous articles from the series “Design Patterns in Automated Testing“, I explained in details how to make your test automation framework better through the implementation of Page Objects, Facades, and Singletons. Here I am going to improve these patterns through mixing them with Unity IoC Container (Inversion of Control). This is going to change slightly the hierarchy of classes and remove some base classes and generic parameters. In the end, the reading of the code is going to be easier.

IoC Container

Definition inversion of control (IoC) describes a design in which custom-written portions of a computer program receive the flow of control from a generic, reusable library. A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the reusable code that calls into the custom, or task-specific, code.

Inversion of control serves the following design purposes: To decouple the execution of a task from implementation.To focus a module on the task, it is designed for.

To focus a module on the task it is designed for.

To free modules from assumptions about how other systems do what they do and instead rely on contracts.

To prevent side effects when replacing a module. In software engineering,) describes a design in which custom-written portions of a computer program receive the flow of control from a generic, reusable library. A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the reusable code that calls into the custom, or task-specific, code.Inversion of control serves the following design purposes:

UML Class Diagram

Participants

The classes and objects participating in this pattern are:

Page Object (WikipediaMainPage)- Holds the actions that can be performed on the page like Search and Navigate. It exposes an easy access to the Page Validator through the Validate () method. The best implementations of the pattern hide the usage of the Element Map, wrapping it through all action methods.

(WikipediaMainPage)- Holds the actions that can be performed on the page like Search and Navigate. It exposes an easy access to the Page Validator through the () method. The best implementations of the pattern hide the usage of the wrapping it through all action methods. ICustomPage – Contains only the signatures of methods of a particular page object.

– Contains only the signatures of methods of a particular page object. BasePage<S, M> – Gives access to the child’s page element map class and defines a standard navigation operation.

– Gives access to the child’s page element map class and defines a standard navigation operation. BasePage<M, V> – Adds an instance to the child page’s validator class through the Validate method.

– Adds an instance to the child page’s validator class through the method. BaseElementMap – Provides easier access to current browser and functions to switch between different frames.

– Provides easier access to current browser and functions to switch between different frames. BasePageValidator<M> – Gives all child validators instance to the current element map and the page object itself.

IoC Container and Page Objects C# Code

Test’s Test Case

The primary goal of the example is going to be to search for a term in Wikipedia and validate functionalities on the found article’s page.

1. Navigate to Wikipedia site

2. Search for Term

3. Validate Contents Hide toggle

4. Click Contents Hide link

5. Validate Contents list is not visible

If we don’t use IoC Container, our test looks like the code below.

The primary disadvantage is the need to create the WikipediaMainPage for every single test. As I discussed in my previous article devoted to Singleton Page Objects, the core framework classes can be modified to produce only a single instance of every page per test run. However, the examined approach in the post brings tremendous complication of the class hierarchy through multiple new generic parameters and classes. Observe this short code example.

To simplify the architecture of the framework, it is possible to use Unity IoC Container for the creation of the page objects. In order to be able to achieve it, a slight change of the main page object pattern’s classes is needed. In this example, I’m going to use the simplified version of the BasePages.

As you can see, the inheritance from singleton class is missing, and the same goes for the half of the generic parameters.

So that to be able to use the IoC Container in the tests the WikipediaMainPage should implement an interface.

The only difference compared to the typical implementation of the Page Object Pattern is the IWikipediaMainPage interface.

It should hold only the publicly available members of the page object, I want to emphasize that the Map property is not present here because it is a bad practice to use it directly in the tests.

For more detailed overview and usage of many more design patterns and best practices in automated testing, check my book “Design Patterns for High-Quality Automated Tests, C# Edition, High-Quality Tests Attributes, and Best Practices“. You can read part of three of the chapters:

Defining High-Quality Test Attributes for Automated Tests

Benchmarking for Assessing Automated Test Components Performance

Generic Repository Design Pattern- Test Data Preparation

IoC Container Page Objects in Tests

In this example, I’m using the simplified registration process of the Unity IoC Container. In the later examples, I’m going to show you how to configure it through XML configuration and abstract the logic in a new PageFactory class.

The AssemblyInitialize marks that the method is going to be executed only once for the current assembly which means that the registration process is going to be executed only once.

Through the following line:

We tell unity that we want to retrieve WikipediaMainPage when we resolve the interface IWikipediaMainPage. The parameter ContainerControlledLifetimeManager is used to point the IoC container to determine the object as a singleton. That means that if we resolve the interface a second time, the same instance is going to be returned.

Configure Unity IoC Container through XML Configuration

First create a new XML file, named unity.config. Mark it to be always copied to the output folder.

Under the unity section, paste the register parts where you need to point Unity how to map your interfaces. The format is as follows- type=”FullNamespace.InterfaceName, AssemblyName” mapTo =”FullNamespace.ClassName, AssemblyName”.

The above line tells the IoC Container to create the specified class as Singleton.

So that the Unity container to be able to retrieve the desired configuration from the file, you need to configure the IoC container to work with it. One way to do it is to add the code to the AssemlyInitialize method.

If the tests use a configuration file, the below row can be removed.

Improve IoC Container Page Objects Further- PageFactory

If I should be honest when I had read for the first time the code that uses directly the Unity to Resolve the page objects, I didn’t like it so much. Because of that, I created a class, and its primary goal was to hide the IoC container’s work and its configuration.

Instead of configuring the Unity in the AssemblyInitialize method, the static constructor is going be called only once and so load all necessary settings.

Usage of IoC Container PageFactory

This way the code is much simpler and easy to read.

“Improve” Page Interfaces through Inheritance

In the previously mentioned IWikipediaMainPage interface, there were present the Navigate and Validate methods that are derived from the BasePage classes. This means that for every page’s interface they should be present too. The same way there are base pages to hold these two standard methods, there could be a base interface.

The refactor version of the IWikipediaMainPage interface is going to look as follows:

Personally I believe that it is better to add these two methods every time instead of complicating the code so much. However, you have always the choice to do it.

Pros and Cons of IoC Container Page Objects Compared to Singleton Page Objects

Cons

Dependency to Unity IoC Container.

Harder to use. Every time you need to resolve the interface to get the page.

Add code through the interfaces.

An additional configuration is required by code or XML.

Pros

Simplified hierarchy of classes.

Possibility to change the lifetime scope of the page objects.

More abstract tests- option to change the page object classes if needed.