Page Objects: Reducing Test Flakiness with Gondola Studio

The Problem

It plagues QA departments everywhere. You have a hundreds of tests written, the dev team decides to make a small change in the GUI and BAM ... they're all broken. In the old days you'd have to rewrite each test. Sure you could copy/paste a lot, but it's tedious and likely to introduce new errors. That maintenance can take a lot time and cost a lot money.

without page objects

The Solution

Now, instead of manually rewriting each test, you can use a Page Object. A Page Object is just what it sounds like, and object-oriented model of page. It contains the locators and methods for interacting with your page. If the devs change "usrName" to "userName" you won't need to change that in each test, just in the Page Object referenced in each of your test. One file instead of many.
with page objects

Page Objects in Gondola

By default Gondola stores its Page Objects in the src/pages folder. Page Objects are made up of Locators and Methods. Let's examine a page object now.

The Locators

Finding Locators for Web Apps

So you've read about web locators. You know about xpath and css locators, but what about finding the best one? POM Builder to the rescue. POM (Page Object Model) builder is a chrome extension for quickly finding the best locators for test automation frameworks.

POM Builder

Finding Locators for Mobile Apps

If you have a mobile app, you can use Appium Desktop to find locators. Appium Desktop allows you to view pages from your apps as Page Objects and select the proper locator. Here's more on finding locators with Appium Desktop.

Adding Locators to your Page Object

Page Object Locators

Using the Gondola Spreadsheet Editor (GSE) we've defined three locators. These xpath locators point to the fields for logging into a web app. If the devs change login_field to loginField, we just need to change it in one file, not hundreds.

Once these locators have been defined, we can access them from our test. Type $ and autocomplete will search your Page Objects for locators.
Locators autocomplete
But we just want to login in using these locators, do we need add code to interact with them in each test? No, we can also add methods to our Page Objects.

The Methods

Page Object Method

Here's a method we can access from our test. Any tests that need to login to the app can use this method. You can access it from your test like this:
method in test

The arguments userName and userPass from the method loginUser are accessible here. If the method for logging in changes in the future (for instance a domain option is added), you can change it in the Page Object instead of each test.

Multi-Platform Testing

Let's say you have a React-Native or Cordova app and you want to test it on iOS and Android. Most of the test will be the same, but the locators will be a little different. Historically you'd have to write a slightly different tests for each platform. The Gondola ILocator interface allows you to set locators for several platforms and Gondola will choose the right one. Currently when using GSE you'll have to define your ILocator with native code like this:
multiple locators

If you create a Page Object and set your ILocators for both platforms, you can then write one test for a React-Native, Ionic, or Cordova app and easily test both the iOS and Android versions of the app.

Conclusion

Maintainability is essential when writing tests for enterprise applications. It allows for continuous testing and monitoring of your application to be be smooth and seamless. Page Objects allow your team to adapt to changes in applications easily and safely. When combined with ILocators your tests can satisfy the "write once, run anywhere" mantra. You can even use them with Behavior Driven Developement. With Gondola Studio and Page Objects application changes only require a minor adjustment, not a stressful event.

Comments are closed.