Using Page Object pattern for testing Pega applications
If you are working with Pega you probably want your application to have the best possible quality, and test automation is natural way to do that. There is a high chance that big part of those tests will be scenario-based UI tests, that revolve around clicking through consecutive views using test scripts.
In this article I would like to present one of best practices for testing which is Page Object Pattern with a simple example.
Why and when it’s useful?
A characteristic of UI automated test is that they usually rely on many different views, and specific elements, that they contain. Scripts for those tests can very easily get unreadable, even for the author, because of enigmatic selectors or ambiguous methods. In some simple applications, where there is not much to change such situation might not have a lot of impact after the test is created. However, when it comes to complex solutions like Pega, maintenance of multiple poorly written test scripts will cause serious problems, and more harm than good.
Page object pattern aims to untangle and extrapolate as much as possible to separate files. That approach improves testing on two levels. First, those elements are more visible and easier to reuse for another tests scenario. Writing additional scripts can be done faster, which projects into better overall quality. Second improvement is that shared elements in page objects are much easier to maintain than if they were scattered across many test files.
What it should look like?
Depending on complexity of tested application or feature one page object should reflect elements and actions that can be taken on one view (screen) of application. If application is less complex, and number of test scenarios are limited, it’s acceptable to have a single page object for the whole flow.
Here’s an example of page object for login screen of Pega Hybrid Client, written in Calabash.