The Power of the POM in Guidewire Test Automation

Page Object Models (POMs) are crucial in test automation, abstracting and encapsulating the complexity of your entire application. From a functional perspective, they enable the creation of effective, reusable, and maintainable test scripts and libraries. But how do you handle POMs for evolving applications and version upgrades?

As Guidewire developers already know, InsuranceSuite is a vast application. Even before configuration, CenterTest generates over 127,000 unique IDs for an out-of-the-box (OOTB) v10 system. Such complexity means that an effective end-to-end, UI-level test automation strategy must be supported by a framework that generates and maintains Guidewire POMs for you. We will cover how this generation process supercharges version compatibility in an upcoming article.

In part four of our Testing Guidewire blog series, we will explore the power of the POM in streamlining and scaling test automation for Guidewire. POM generation is core to CenterTest’s power and is critical for successful Guidewire test automation. This article will discuss how Guidewire’s architecture adheres to object-oriented principles such as inheritance and encapsulation, enabling our CenterTest abstraction layer to generate POMs for your individual implementation. While CenterTest also generates a Product Model library and helper utilities to simplify automation, this article will focus on the interactive UI layer – the pages.

We will also examine why we need to generate POMs given the scale of InsuranceSuite, and how the brilliance of Guidewire’s PCF architecture makes generation possible. Let’s start by getting a grasp on the scope of the issue as it relates to Guidewire.

CenterTest generates compatible POMs for every version of Guidewire, ensuring rapid implementation and version compatibility for your automated tests. With CenterTest’s abstraction layers handling DOM interactions, test writers can effectively interact with browser pages without needing knowledge of Guidewire architecture, Selenium, or Playwright.

The Scale Challenge in Testing Guidewire

One of the primary challenges in testing large-scale applications like Guidewire’s InsuranceSuite is their sheer size and complexity. To illustrate this, let’s examine the POMs generated by CenterTest for an out-of-the-box (OOTB) Guidewire implementation.

First, let’s establish some basic definitions:

• Pages: The physical pages that users will interact with at runtime; they don’t exist as a whole but are dynamically built during execution. They are composed of PCFs.
• PCFs: Page Configuration Files are the building blocks of Pages and contain the low-level, interactive elements that are the fields on a screen. They rely heavily on OO principles.
• Components: Components are based on the PCFs but there is not a one-to-one correlation between Components and PCFs. They are CenterTest’s way to support its generated Pages during test execution.
• Typelists: Drop-down list entries are configurable during development and are dynamic at runtime.
• Unique IDs: HTML IDs dynamically generated at runtime that represent each individual field within each generated page.

Next, let’s look at some numbers to understand the scale of a Guidewire system and underscore why designing for testability is critical in such a complex system. Notice that over 2,000 pages are generated, with over 127,000 unique IDs amongst them (each ID represents a unique field or XPath across pages).

These numbers are staggering. To truly appreciate the complexity and difficulty to effectively test Guidewire, let’s drill down on a single field: City in the GlobalAddressInputSet PCF.

City alone is referenced in 152 components, resulting in 152 unique IDs. For example:

• AccountFile_Contacts-AccountFile_ContactsScreen-AccountContactCV-AddressesPanelSet-AddressDetailDV-AddressInputSet-globalAddressContainer–GlobalAddressInputSet-City
• SubmissionWizard-LOBWizardStepGroup-LineWizardStepSet-PADriversScreen-PADriversPanelSet-DriversListDetailPanel-DriverDetailsCV-AddressesPanelSet-AddressDetailDV-AddressInputSet-globalAddressContainer-GlobalAddressInputSet-City
• IssuanceWizard-LOBWizardStepGroup-LineWizardStepSet-LocationsScreen-LocationsPanelSet-LocationsEdit_DP-LocationDetailCV-LocationDetailDV-LocationDetailInputSet-TargetedAddressInputSet-globalAddressContainer-GlobalAddressInputSet-City

Due to Guidewire’s object-oriented (OO) architecture, you can see all three of them drill down to the same endpoint: GlobalAddressInputSet-City, but taking three different paths.

This consistency amid complexity is a key feature of Guidewire’s architecture (see our previous article Designing for Testability). The sheer number of pages, components, and unique IDs in Guidewire makes manual maintenance of test scripts impractical. As the application evolves, the structure and identifiers of elements can change, leading to broken tests and increased maintenance efforts.

This overwhelming complexity underscores the necessity for an advanced solution to manage and maintain these elements efficiently. CenterTest addresses this need by generating compatible POMs for every version of Guidewire, ensuring rapid implementation and version compatibility for your automated tests.

Let’s explore how CenterTest harnesses Guidewire’s architecture to create a robust test automation framework.

Page Object Models (POMs): The Cornerstone of UI Automation

Effective test automation mirrors human actions, emulating real-world processes like logging in or adding an account. This approach simplifies test creation and maintenance, keeping tests intuitive and relatable for all stakeholders. Automation must interact with the same physical screens as users to replicate these interactions effectively.

Let’s start by looking at a physical screen, then an example of how we might create a basic person account:

Now let’s examine the associated POM for the same page:

Notice the object-oriented principles and POM usage at play in this example:

• Abstraction: The POM (CreateAccountPage) abstracts the structure of the page supporting access to and interaction with the raw elements.
• Encapsulation: Complex elements like contact and address are encapsulated within their own objects, highlighting the object-oriented design we discussed earlier.
• Flattened Architecture: Despite the underlying complexity of Guidewire, you can easily set values for various fields using a flattened structure.
• Separation of Concerns: The POM provides access to the runtime page and methods to interact with page elements, while the test contains the logic of what data to input and when.

It’s important to note that, in practice, POMs are significantly more complex and can include complex structures such as tables, rows, and columns. However, this example serves to illustrate the basic concept.

By leveraging POMs, we create tests that are not just robust but also adaptable to UI changes. This flexibility is crucial when dealing with dynamic systems like Guidewire or any large-scale application.

Next, let’s look at some sample CenterTest code for the same page, with in-line comments explaining our approach:

Notice how CenterTest POMs enable the creation of clean, maintainable, and readable tests that can automatically adapt to changes in the underlying application. The POM’s structure allows for intuitive navigation of complex page elements while hiding the implementation details of how these elements are located and manipulated on the actual web page.

For example, CreateBasicPersonAccountData directly corresponds to the POM structure. Each element is accessed through methods defined in the POM, abstracting away the complexities of an element’s location and interaction, making the code intuitive and easy to maintain.

While these examples provide a good foundation for understanding the value of POMs, let’s dive deeper into how we utilize POM identifiers to form the backbone of CenterTest’s ability to locate and interact with elements in Guidewire’s vast and dynamic interface.

The Brilliance of Guidewire’s Architecture – the ID and more

The brilliant design of Guidewire’s PCF architecture is why CenterTest can generate POMs in the first place. Guidewire’s architecture is a great example of object-oriented principles like inheritance and encapsulation, where PCFs incorporate each other in complex hierarchical structures. In other words, many PCFs are reused by other PCFs, providing reusability through inheritance by design.

We already saw how the POM provides the page structure, now let’s look at how CenterTest helps you get to the elements. This is often the most brittle and commonly broken part of test automation. CenterTest addresses this problem with four different ways to identify and maintain elements, each with its own set of advantages:

Method 1: HTML ID

Element IDs are native to HTML architecture. Guidewire ensures each ID within any given DOM element is unique within that page, even if the same field appears multiple times. CenterTest uses these IDs almost exclusively with CSS ID Selectors.

Fortunately, Guidewire requires IDs for most PCF elements, letting Guidewire build IDs dynamically at runtime, guaranteeing unique IDs within each page.

Without CenterTest, you would need copy and save each ID from the application at runtime into a POM, or build your own POM generator to determine the IDs. This generation process is incredibly complex; IDs may be only a few characters long or well over 100 characters long. CenterTest understands that the same element can occur multiple times and natively handles the unique “duplicate” logic of Guidewire for you.

CenterTest provides you the most efficient and direct way to get to any element for automation, without needing an in-depth understanding of the DOM to write tests.

Method 2: data-testid

A commonly accepted practice is to use the custom HTML property “data-testid” instead of the HTML ID of each field. Though “data-testid” is not utilized at all by Guidewire, CenterTest can use it to test third-party applications or custom portals.

From a design perspective, Kimputing recommends using “data-testid” because it is easy to add to your elements, can be given meaningful names, is less susceptible to development changes, and, most critically, does not need to be unique within the page.

Since there can be multiple elements on a page at the same time with the same data-testid, CenterTest provides ways to extract the required element within its relationship to the DOM.

Method 3: Parent/Child Relationships

When IDs and data-testids are not the best way to find elements, navigating the DOM structure may be the next best choice. People intuitively understand relationships; let’s use a table as an example.

First, you must identify the table you are looking for on the screen, then the specific row based on filtering criteria like column names, then extract the specific information by column(s) within that row. Very natural. CenterTest handles these complexities for you, making it much easier and faster to write your tests.

Parent/Child structures are easy to break during development, but with CenterTest, you simply regenerate your POMs to repair your tests.

Method 4: By Label

A less reliable but straightforward way to locate elements is by searching for labels. This involves identifying an element’s associated label, like “First Name,” and retrieving its value.

While simple, this method is fragile and should be a last resort due to its complications with multi-lingual support and the risk of label changes during development and maintenance. However, it can be necessary for retrieving dynamic content, such as a generated drop-down menu of contacts.

Interacting with your Elements – Widgets

Guidewire includes over 175 types of complex UI components known as widgets. These widgets are sophisticated, dynamic components that represent various inputs, displays, or interactive elements like dropdown menus, date pickers, autocomplete fields, multi-select boxes, table and row processing, and section grouping.

While the primary purposes of a POM are to provide a view of the page and access HTML elements for interaction, CenterTest adds a third purpose: the Widget abstraction layer. This layer encapsulates each Guidewire widget within a specialized CenterTest widget.

This process supports automation by supporting simple actions such as selecting values from a dropdown list or complex operations like searching rows in a table or interacting with multi-element widget.

Let’s consider some examples of how CenterTest widgets abstract away the complexities of interacting with different types of Guidewire widgets:

You can see how critical these widgets are to effective automation. For example:

• WidgetAddressAutoFillInput – Prefills known address information directly from a valid postal code.
• WidgetTypeKeyInputAddressType – Specialized dropdown list with options such as Billing, Business, and Home.
• WidgetPrivacyInput – Privacy field that protects/hides the data on the screen and within the DOM.

These widgets handle all the necessary steps to interact with the elements including navigating the Dom structure, setting values, and even verifying the results.

CenterTest abstraction significantly simplifies test creation for Guidewire. For instance, interacting with the drop-down list typically requires three steps: getting the element, clicking to open the list, and selecting the desired option. With CenterTest, this is reduced to a single step: set value. This not only makes the code more concise but also more readable and maintainable.

Here are some of the key aspects of CenterTest’s approach:

• Getting to the Element: In many complex widgets, the provided locator ID does not get to the needed element but to a parent element within the structure. CenterTest widgets navigate the DOM structure when necessary to get to the explicit element needed. This occurs in widgets such as WidgetTypeKeyInputAddressType.
• Widget-specific Interactions: CenterTest provides custom methods tailored to different types of widgets. For example, the WidgetPrivacyInput widget accepts data but hides its data, while WidgetTextInput is a basic input/display process for many fields.
• Dynamic Wait Strategies: Given the dynamic nature of many Guidewire widgets, CenterTest implements intelligent wait strategies to ensure that elements are in the expected state before interaction. This is handled automatically in operations like set().
• Error Handling and Reporting: When interacting with complex widgets, things can go wrong in unexpected ways. CenterTest includes robust error handling and detailed reporting to help diagnose issues in widget interaction. If a set() or assertEquals() operation fails, CenterTest will throw an exception with detailed information about the failure.
• Built-in Asserts: Assert functionality is built into the CenterTest widgets to accommodate the complexities of data-driven testing. CenterTest supports both hard asserts and soft asserts (asserts that don’t fail prematurely if you are testing many things).
• Automatic Verification: As a bonus, every time you perform a set operation with a widget, CenterTest automatically waits for the set to complete and verifies that the set worked. If something fails during this process, an assertion exception is thrown. This built-in verification adds an extra layer of reliability to your tests without requiring additional code.

This approach allows testers to create clean, readable, and maintainable tests that can effectively interact with Guidewire’s complex widget ecosystem, regardless of the specific context or behavior of each element. The widgets themselves encapsulate all the necessary logic for proper interaction, eliminating the need for testers to handle low-level details or implement separate best practices for each widget type.

Wrap-up

We hope you now understand how Guidewire’s PCF architecture is fundamental to its testability and exemplifies object-oriented design. This makes Guidewire a perfect candidate for POM generation and automation using a sophisticated framework like CenterTest.

The concepts explored, from POMs to element identification and widget interaction, provide insights into Kimputing’s approach to test automation:

• CenterTest generates POMs directly from your unique Guidewire source code.
• CenterTest POMs incorporate the unique IDs produced by Guidewire at runtime for every element.
• CenterTest custom widgets abstract every internal Guidewire widget.

Understanding Guidewire’s architecture and patterns allows CenterTest to create and maintain effective POMs and product models. This provides a robust automation framework allowing you to implement customized test automation in just a few weeks while increasing speed to market, reducing automation maintenance, enhancing test coverage, and ensuring scalability.

The effectiveness of this approach was proven during the Hakuba update. In just a few hours, the Kimputing team released a CenterTest update to adapt to Hakuba’s DOM changes, ensuring minimal downtime for clients. Other organizations using different frameworks took weeks of refactoring and manual maintenance to get their tests working again.

For more on Guidewire testing and automation, stay tuned for upcoming articles in our Testing Guidewire series where we will review all of CenterTest’s features and functions, and explore how CenterTest supercharges Guidewire Cloud migrations through version compatibility by allowing tests written in v8 or v9 to run in the Cloud.

---

A special thanks to the Kimputing team for their contributions to this article, Raivis Sarkovskis, Arkadiusz Frankowski, and Duncan Guignet.

Kim Filiatrault
Founder and President

---

Watch or read our other posts at Kimputing Blogs. You’ll find everything from Automated testing to CenterTest, Guidewire knowledge to general interest. We’re trying to help share our knowledge from decades of experience.