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.
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.
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.
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.
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
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
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.
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.
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:
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.
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:
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.
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.