In my previous articles from the series “Design Patterns in Automated Testing“, I explained in details how to improve your test automation framework through the implementation of Page Objects, Facades and Singletons. Here I am going to extend further the ideas of the Page Object Pattern. More efficient usage and improved readability are achievable through the incorporation of the Page Objects with Fluent API. The result will be Fluent Page Objects or Fluent Page Object Pattern.

Fluent Interface

Definition software engineering, a fluent interface (as first coined by Eric Evans and Martin Fowler) is an implementation of an object-oriented API that aims to provide the most readable code.A fluent interface is typically implemented by using method cascading (concretely method chaining) to relay the instruction context of a subsequent call (but a fluent interface entails more than just method chaining). The context is defined through the return value of a called method-self-referential, where the new context is equivalent to the last context.

Self-referential, where the new context is equivalent to the last contest terminated by the return of a void context.

Terminated by the return of a void context. In, a(as first coined by Eric Evans and) is an implementation of an object-oriented API that aims to provide the most readable code.A fluent interface is typically implemented by using(concretely) to relay the instruction context of a subsequent call (but a fluent interface entails more than just method chaining).

UML Class Diagram

Participants

The classes and objects participating in this pattern are:

Page Objects (SearchEngineMainPage)- 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.

(SearchEngineMainPage)- 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. 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<S, 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. BaseSingleton – This is an abstract class that contains a static property of its child instance BaseSingleton – This is an abstract class that holds a static property of its child instance.

– This is an abstract class that contains a static property of its child instance – This is an abstract class that holds a static property of its child instance. 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<S, M, V> – Gives all child validators instance to the current element map and the page object itself.

While ago we were working on the first version of the BELLATRIX test automation framework, I did this research so that we can find the most convenient way for creating page objects.

Fluent Page Object Pattern C# Code

Test’s Test Case

The primary goal of the example test for the Fluent Page Object Pattern is going to be to search for images in SearchEngine with different settings.

1. Navigate to SearchEngine site

2. Search for Term

3. Switch to Images tab

4. Change query settings

Fluent Page Objects Implementation Code

If we don’t use Fluent Page Objects, our test looks like the code below.

The primary goal of the Fluent Page Object Pattern is to enable you to use the power of method chaining. To achieve it, the SearchEngineMainPage should be slightly modified.

The most important part of the above code is that all methods return the current instance of the page.

Not quietly related to the pattern itself but interesting to point here is the way of choosing the different options. All of them are of type SelectElement. Here are the different settings elements that you can discover in the SearchEngineMainPageMap.

All of them use the same location technique- XPath expression that finds the div by its inner text.

I believe that it is a poor decision to switch settings through text variable, so in my implementation I use enums.

Sample Settings Enum

This way the chosen enum value represents an integer from 0-4 that is the same as the index of the same values in the select element.

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

Create Fluent Page Validator

In order to keep the method chaining available even after a usage of validation methods, a modification of the BasePageValidator is mandatory too.

Not Fluent Version

Fluent Version

All changes are applied to provide us access to the current Page instance, in order to be able to return it every time in our validation methods.

Not Fluent SearchEngineMainPageValidator

Fluent SearchEngineMainPageValidator

Because of the changes in the BasePageValidator the BagePage classes should be modified to support the new fluent base validator.

Fluent Page Objects Usage in Tests

The fluent page objects significantly improve the readability of tests. Also, it is quite easy to write tests, thanks to the method chaining.