Guys, I am so excited to announce the creation of new series of blog posts- Design & Architecture. The main idea behind this is that I will show more abstract, visionary improvements that you might bring to your test automation projects that do not depend on the used test automation framework such as WebDriver or Testing Framework. The first articles from Design & Architecture Series are going to be dedicated to the creation of a Hybrid Test Automation Framework. Through this type of test automation framework, you can quickly execute your tests through different test automation frameworks without changing a single line of code, using only configuration switches. As you may guess, the creation of a Hybrid Test Automation Framework is not an easy job. A lot of code should be written so I cannot explain everything in a single post. Because of that, I am going to separate logically in the best possible way the content. In this first article, I am going to explain to you how to create the core interface contracts that your test pages and tests will use so that they do not depend on a concrete implementation and at the same time follow the best practices and SOLID principles.

Hybrid Test Automation Framework- Interfaces Primary IDriver Interface This is the main interface that you will use in your code. As you can found out from the lines below it does not contain any methods, it only inherits a couple of other important contacts. The main idea behind this is to follow the Interface Segregation SOLID Principle. If you need to find elements, you will use the IElementFinder interface if you require updating cookies you will use the ICookieService and so forth. The principle states that no client should be forced to depend on methods that it does not use so we split the big interface in several smaller logically separated parts.

IElementFinder Interface

The IElementFinder contract holds methods for locating elements on the pages. Also, it contains a logic for checking if an element is present. The methods return IElement interface which represents a base HTML page element.

To support searching of elements inside other container items such as DIVs, IElement inherits from the IElementFinder interface. All different controls will inherit from the IElement contract. You will find more information about this in the next articles from the series. Similar to the WebDriver implementation we have an abstract static class By for setting the elements' localization strategy.

IJavaScriptInvoker Interface It holds a logic for JavaScript execution.

INavigationService Interface INavigationService interface has several methods regarding navigation such as navigating by a relative URL or absolute URL. Also, it contains logic for waiting for specific URL.

IDialogService Interface Through it, you can handle different dialogs.

IBrowser Interface This is one of the most important interfaces, part of the main IDriver interface. Through the IBrowser contract, you can execute browser-specific actions such as switching frames, refreshing, clicking back/forward buttons and so on.

Hybrid Test Automation Framework in Tests This is how will look like the base page for all pages of your hybrid test automation framework. Hybrid Test Automation Framework Base Page

As you can see the base page does not require all interfaces of the IDriver contract. Most pages need only a way to find elements and to navigate. Non-Hybrid Base Page To see the difference, you can find below the code of the non-hybrid version of the BasePage class.

As you can see, we pass the whole IWebDriver interface. However, often we do not need all methods that it exposes. Hybrid Page Object

Similar to the base page, here we pass only the abstract hybrid test automation framework's contracts. Also, we need to implement the Navigate method manually. Non-Hybrid Page Object

The only difference compared to the hybrid version is that the SearchEngineMainPage is coupled with the concrete IWebDriver implementation. Hybrid Page Map

Here I used the improved version of the Page Object Pattern- the element map is implemented as a partial class of the primary page object class. We use the ElementFinder property that comes from the BasePage class to locate the different elements. As you have probably noticed, the different properties return the IElement interface so that the map is not coupled with the concrete implementation of the controls. Non-Hybrid Page Map

Similar to the page object class the non-hybrid element map is coupled with the WebDriver's concrete implementation. Hybrid Test Automation Framework Test Example