Locators and Page Objects Pattern

Locating elements is the art you need to master for building robust tests in Selenium .

The “Hello World” case where you locate your element with a fixed ID never works in practice because today most of the IDs are dynamically generated.

Name and attributes, XPath locators, and CSS selectors, all these types of locators need to be mastered to avoid flaky tests.

With Boozang, as we will see in Chapter 8, “Elements Location Approach,” you can most of the time forget about element location strategies.

The Page Object Pattern is recognized as one of the best practices when using coded tools like Selenium. It was proposed in 2009 in the SeleniumHQ wiki page ( www.selenium.dev/documentation/test_practices/encouraged/page_object_models/ ) and later promoted by Martin Fowler in a famous blog post ( https://martinfowler.com/bliki/PageObject.html ).

Page objects are meant to abstract the physical structure of a web page and provide an API that is more oriented toward that page’s actual services. For each web page, you usually build one or more page objects. You can also have a single page object for a section of the page used multiple times within a website or application.

Page objects make your tests more robust: if an element of the page changes, you don’t have to modify all the tests using this element but rather a single page object.

Assertions should typically not be included in a page object, and in general, good page objects should not contain any details of the business logic. Their sole responsibility should be to locate elements and provide methods to interact with them.

With modern Web UIs and development frameworks like React¹ and Angular,² page objects can quickly become hard to maintain.

Writing good page objects is not straightforward, and it requires a good experience. But it is also a crucial aspect that can make the difference between a maintainable suite and an abandoned one.

On top of page objects, you usually define business actions as methods, which are low-level use cases on how users interact with your application to achieve a well-defined objective. These mini use cases are what Alistair Cockburn places at the “indigo” level (under the sea) in his Writing Effective Use Cases (Addison-Wesley Professional; 1st edition, October 5, 2000).

The good news is that with Boozang you can forget about page objects and focus directly on the mini use cases, removing one layer of complexity.

Browsers and WebDriver Compatibility

How many times did you find your scenarios all red in your nightly run and discovered that Chrome had just released an update which was not compatible with your WebDriver version?

You head up to https://sites.google.com/a/chromium.org/chromedriver/downloads , download and install the correct version, and you need to re-run all your scenarios.

Not too bad you might think, unless this happens the day before you scheduled a production deployment, when your tests have to give the green light.

Boozang, unlike other solutions, does not rely on the WebDriver API. This means that you can completely forget about browser and WebDriver compatibility!

Timing and Waits

Modern web applications use Ajax, Javascript components, and elements on the page can be loaded at different times. If you do not make proper use of explicit waits, you will get the infamous ElementNotVisibleException, with your screenshot on the failed tests clearly showing that the element you wanted to locate is clearly there.

With Selenium, the default implicit wait is 0, but depending on the SUT you can set it to 5 or 10 seconds. This means that Selenium will wait 5 or 10 seconds before throwing the ElementNotVisibleException.

Explicit and fluent waits allow you to instruct Selenium to wait for a specific condition, like an element to be visible or clickable on a page, until a timeout that you define. In the explicit wait, the polling frequency is fixed to 250ms, while in the fluent wait you can specify the polling frequency.

With Boozang, the implicit wait is possible on each action with the delay attribute. Explicit waits are then handled with timeouts. Moreover, you can specify a fail element to avoid lengthy timeouts (see more in Chapter 9, “Exit Conditions, Conditional Flows, and Timers”).

Data Management

When you build your automated tests relying purely on the WebDriver APIs, the framework’s quality depends on the skills and experience of the developers who build and maintain it.

On the other hand, you have full control and flexibility over what you can do.

Same as for software development, the danger is to build something that ends up being hard to maintain. And the risk is higher when more people are involved in maintaining the tool. This is something you should consider, especially in an enterprise environment.

Proper data management is even more critical when you start running your tests in parallel.

Besides the fact that each test should create its own data set to avoid conflicts, each scenario should run independently from the others.

We dedicate an entire chapter to Data Management with Boozang (Chapter 9, “Exit Conditions, Conditional Flows, and Timers”). The advantage of using a tool like Boozang is that it comes with its own data management capability, and you just have to use it. It might feel constraining to developers, but the advantage of having a standardized way of working with data can make the difference in the long run. We will see how Boozang, with its powerful data management capabilities, addresses the flexibility needs of most developers and keeps it as simple as possible for non-developers.

Reporting and Script Readability

When a test fails, you want to be able to find out the root cause quickly.

The quality of the test reports directly influences the time needed to troubleshoot failed tests. And the time required to troubleshoot the failures is a direct measure of your test suite’s quality.

A framework built with Selenium needs to provide its custom reporting system or produce reports in a standard JUnit or Cucumber format. All this takes time away from developing scenarios.

Tools like Boozang come with their reporting features, allowing you to focus on writing scenarios. Boozang has its custom reports, both for local and CI-based runs, but it also provides JSON cucumber reports that you can easily publish on Jenkins or other dashboards.

While troubleshooting, the first thing to look at is the action in error and its details, like an element not found or a failed validation. This information, together with a screenshot, gives you a good idea of the root cause.

If you want to dive deeper into what happened before the failure, the coded approach will give you the error in the form of a stack trace. This sequence of method calls can be quite hard for a non-developer to understand.

In Boozang, a test is a sequence of actions that are human-readable. The execution reports are a sequence of tests called within a scenario, and they are easy to understand. Most of the time, you don’t even need to know the tool to understand what went wrong.

Development Skills

Locators, WebDriver, and browser compatibility, timing, data management, and script readability are just some of the most critical aspects of the complexity behind a Test Automation framework based on Selenium.

I honestly thought this was the price to pay for having a maintainable suite, until I discovered Boozang.

We already discussed the role of SDET in section “Testing Roles.” The reality, though, is that we are not all like Google.

The learning curve of your Test Automation framework is a good indicator of its time resilience.

The harder your framework is to learn and maintain, the higher are the chances of being abandoned over time. The learning curve of Selenium is quite steep.

The WebDriver API supports different languages, from Java and JavaScript to Ruby and Python. You might find a person that already knows the WebDriver API in Python, but that won’t help if you developed your framework in Java.

A key point I will stress later on for tools like Boozang is the shallow learning curve and the fact that only a general software development background is needed to use it effectively.

In particular, I believe that Boozang is very easy to learn thanks to its well-designed User Interface and pure focus on Test Automation.