Table of Content¶
Introduction¶
Page Objects are a widely used design pattern for test automation frameworks. It allows the abstraction of Squish APIs behind frames/windows that specify the user interaction in more intelligent and meaningful ways. With Page Objects, it is simple to encapsulate test script code and make future maintenance of test scripts easy and much less painful. Designing your test automation solution based on Page Object patterns requires the creation of two layers:
Business layer
Technical layer
Splitting your test automation framework into layers has many advantages. One of them is a better allocation of team members working on test automation. Those with technical and programming knowledge develop and maintain the test automation framework. Using this custom framework, your QA Specialists, having a vast knowledge of the application functionality, but without programming skills will be able to create robust, maintainable and efficient automated test cases easily. Other advantages include reduced maintenance effort, more straightforward troubleshooting and faster adaptation for ever-changing applications under test.
Business layer¶
This layer contains test script code at a very abstract level, easy to create and read even by non-technical team members. Test cases are very short and self-explanatory, focused on functionality tested, not on how the application under test is built. While applications evolve, test script remains unchanged (unless application functionality changes).
Technical layer¶
This layer contains interaction with the Application Under Test using the Squish API. It takes full advantage of Object Oriented Programming, enabling modular design and a reusable test automation framework. In general, a Page Object is a class representing a part of an application (usually a single page, frame, sub-frame, window or dialogue). This class provides an interface to interact with the application at very abstract level. Page Object frameworks must be designed to fulfill the following rules:
Do not expose the internals of the frame
Methods represent the actions the frame offers
Methods may return other Page Objects
Do not make assertions inside Page Objects
Example¶
Let's start by defining what services the AddressBook frame offers a user. In this frame we can create a new entry, save or edit an address book. Additionally the user can view all entries in the address book. In the example below the AddressBook class is created offering the following methods: new (creating new address book), add (adding entry to existing address book), entries (returning lists of all entries in address book), rowcount (returning number of entries in address book).
In the AddressBook class method add returns a new Page Object, because after pressing the menu option "Add", the new dialog window displays as "AddressBook - Add". Therefore this window is represented by a separate Page Object called AddressBookAdd.
In above examples, we use class constructor (init method) as a place for extra synchronization and logging. Any extra code that needs to be executed when a new frame is opened can be put there.
The last piece of the framework is the PageObject class, which contains generic methods, which can be used for every frame. Every PageObject defined in test framework inherits from the PageObject class. In this example, we defined method fill to enter text into any text field in the frame.
Finally, we need to prepare the test case that will check a basic scenario in the address book application.
After executing the test case in the Squish IDE, we can check the Test Results view. All test steps are generated there by the Page Object framework, and therefore are consistent with all test cases for the given application. Moreover, each log represents functional steps in the test cases, which makes an analysis of potential defects in the application more convenient.
Squish IDE: Test Results View