Here I will present to you the third version of the Failed Tests Analysis engine part of the Design Patterns in Automated Testing Series. We are going to utilise the power of the Decorator Design Pattern to create the most improved version of the engine.

Definition

Definition The Decorator Design Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

UML Class Diagram

Participants The classes and objects participating in this pattern are:

Component – Defines the interface for objects that can have responsibilities added to them dynamically.

– Defines the interface for objects that can have responsibilities added to them dynamically. Decorator – The decorators implement the same interface(abstract class) as the component they are going to decorate. The decorator has a HAS-A relationship with the object that is extending, which means that the former has an instance variable that holds a reference to the later.

– The decorators implement the same interface(abstract class) as the component they are going to decorate. The decorator has a HAS-A relationship with the object that is extending, which means that the former has an instance variable that holds a reference to the later. ConcreteComponent – Is the object that is going to be enhanced dynamically. It inherits the Component.

– Is the object that is going to be enhanced dynamically. It inherits the Component. ConcreteDecorator – Decorators can enhance the state of the component. They can add new methods. The new behavior is typically added before or after an existing method in the component.

What Are the Problems That We Try to Solve? The previous two solutions of the problem were fine. However, I think that they have a problem with the integration in the hybrid test framework's engine. I didn't want to modify the existing ElementFinderService and couple it with the exception analysis engine. Also, the registration of named instances in Unity IoC container and their resolution through a service locator didn't seem to be the best available solution. Decorator Design Pattern for Failed Tests Analysis IExceptionAnalysationHandler

The IExceptionAnalysationHandler is the primary interface for all handlers. This is an additional abstraction above the Handler base class. IExceptionAnalyser

In the first two solutions, there wasn't an interface abstraction for the ExceptionAnalyser. However, we need it for the observers' version. ExceptionAnalyser

As you can see, the new improved version of the ExceptionAnalyser doesn't use any design patterns. When it starts to analyse the exception it just iterates through the list of all handlers. Also, another significant change is that it doesn't use Unity IoC container to create the handlers. The main application chain of handlers is passed as a collection through the constructor. I am going to show you how the resolve magic happens through Unity a little bit later. IUiExceptionAnalyser

For UI tests, I created the new IUiExceptionAnalyser interface that defines a method for registering new custom test-case-specific handlers for searching for a particular text in the HTML source code. UiExceptionAnalyser

The concrete implementation of the UiExceptionAnalyser is a successor of the ExceptionAnalyser and only adds the method for addition of new CustomHtmlExceptionHandlers to the chain. HtmlSourceExceptionHandler

The implementation of the HtmlSourceExceptionHandler is identical to the ones of the previously proposed solutions with the only difference that it implements the IExceptionAnalysationHandler. Now all handlers implement this interface so that the primary chain can be resolved as an IEnumerable collection through the Unity container. ExceptionAnalysedPage

In order a page to be able to use the exception analysis engine it needs to inherit the new ExceptionAnalysedPage base class. It adds a new property to all pages- the UiExceptionAnalyser so that they can add custom handlers where needed. Also, here the new decorator classes are created so that when an element is not found the exception analysis engine to be called. The same is valid for the navigation engine. If the waiting for a particular URL fails, the engine will be called. Most importantly, the pages and the decorators should share a common instance of the exception analysis engine because of that we assign the decorators' instance of the engine to the base page's property. Otherwise, the pages' added handlers won't be executed. ExceptionAnalyzedElementFinder Below you can find the code of the decorator of the ElementFinder. It contains a property of the original ElementFinder and more or less calls its methods. It implements the IElementFinder interface which means that it has the same methods as the original ElementFinder class. It adds the calls to the Analyse methods if the localisation of some element fails.

ExceptionAnalyzedNavigationService The structure of the NavigationService decorator is the same as the one of the ElementFinderService. We call the analysis engine if the waiting for a particular URL timeouts.

While ago when we were working on the first version of the BELLATRIX test automation framework, I did this research while I was working on a similar feature for our solution.

Decorator Design Pattern in Tests ExecutionEngineBehaviorObserver

Through the first line of code, we tell Unity that when an IEnumerable collection of IExceptionAnalysationHandler is required, to create it from all types registered for this particular interface. Because the decorators don't have empty constructors, we need to instruct Unity how to deal with their initialization. For the job, we use InjectionFactory objects. LoginPage

The usage of the new pages' property is straightforward. First, the page needs to inherit from the ExceptionAnalysedPage base class. Then you first add a custom handler and after that removes it from the chain once it is not more required. LoginProductSiteTests