BDD and CenterTest Narratives for Guidewire

Introduction

Behavior-driven Development (BDD) is a popular software development approach that encourages collaboration between developers, testers, and business stakeholders. Despite its popularity, BDD is often misunderstood or oversimplified, with many associating it solely with Cucumber or Gherkin and overlooking its core collaborative principles.

In addition, there is a tendency to overemphasize the given-when-then syntax, leading to rigid scenarios that may not effectively capture complex business logic. Furthermore, BDD can blur traditional development roles, making implementation difficult by confusing teams that are used to having clearly defined responsibilities.

This article aims to demystify these misconceptions, exploring BDD’s key components and clarifying the distinctions between the methodology and its associated tools. Additionally, we’ll introduce Kimputing’s Narratives, a new approach that aligns with BDD principles while addressing common limitations in complex systems like Guidewire.

BDD vs Gherkin vs Cucumber

A common misconception about BDD is its direct association with Cucumber and Gherkin. While these tools support BDD, they are neither synonymous with it nor required. BDD is focused on collaborative behavior specification, while Gherkin and Cucumber focus on the implementation aspects. Understanding each of these is crucial for success with BDD.

BDD is not a framework, it is a methodology that encourages collaboration by describing software behavior in a way understandable to all stakeholders. The Specification layer ensures a shared understanding of the requirements and expected outcomes among developers, testers, and business stakeholders alike, leading to improved quality and alignment with business goals.

Gherkin is a natural language commonly used to write BDD test cases. It supports the Communication layer by providing a clear, human-readable syntax for defining the expected behavior of software. While Gherkin is not required for BDD, it helps bridge the communication gap between technical and non-technical team members by making the behavior descriptions accessible to everyone involved.

Cucumber supports the Execution layer by translating the human-readable Gherkin into executable code that interacts with test endpoints. For example, Cucumber can integrate with technologies like Selenium or Playwright to perform automated testing of web applications. This allows teams to validate that the software behaves as specified in the Gherkin scenarios. However, the code to execute the steps and business logic must still be written, updated, and maintained manually in most cases.

Challenges and Limitations of Gherkin and Cucumber

The given-when-then constructs in BDD frameworks, while helpful, can be restrictive and insufficient for complex validation. As an example, we have taken a sophisticated, end-to-end, automated UI test written in CenterTest for Guidewire, and converted it to a very basic Gherkin-style script.

To be clear, the original test in CenterTest is functional and we will review the actual test later in this article. The Gherkin below is auto-generated by an online tool and is for illustration purposes only.

This test is data-driven and touches both PolicyCenter and BillingCenter for the Personal Auto LOB and utilizes both a producer and super user role. The purpose of the test is to validate the “Policy Not Taken” cancellation process triggered when a policy is issued, but the initial/down payment is not received, and the policy flat-cancels back to inception.

To accomplish this, the test must:

• Create a new Person Account.
• Create a new Personal Auto Submission in PolicyCenter.
• Verify the policy has been issued and retrieve and save the first payment date information from BillingCenter.
• “Time travel” to the first payment due date, run an invoice batch job and validate that the policy is showing non-payment delinquency in BillingCenter.
• “Time travel” to the day after the first payment due date, run an invoice batch job, and validate that the delinquency has been resolved in BillingCenter because the policy was “not taken”.
• Search for the policy in PolicyCenter and validate that the policy was canceled for non-payment.

While we would consider this a sophisticated, end-to-end test for Guidewire, the entire process is relatively simple with CenterTest. Now that we understand what the test is supposed to do, let’s examine the sample Gherkin below.

Reminder: The functional version of this test for CenterTest will be reviewed next.

For the purposes of this exercise, we are assuming a single E2E Gherkin script can touch multiple Centers, utilize multiple user roles, and automatically time travel to the best day. Let’s review a few of these steps to determine what else the Gherkin steps or underlying definitions will need for this test to work as intended.

• Given the producer is logged into PolicyCenter. What endpoint are you going to? What username and password are needed for producer? Do they change with the environment? How are your credentials managed?
• When the producer creates a new person account with the given data. How do you get to the account page after logging in? Is the account information spread across multiple pages – and what if that changes during development? How do you save the new account? How do you verify the account was successfully saved?  Was the information saved correctly, such as truncation and case sensitivity?  How does the test access and retrieve the data to create the account?
• And the producer submits a personal auto policy. How do you start the submission process? What account do you use to create the submission? There are both required and optional steps when creating a personal auto policy – how does the test access and retrieve the relevant data, and how does it know which fields to populate? How do you complete the submission? How do you validate the quote? Do you need to bind the quote? If so, how?
• And the super user searches for the policy in BillingCenter. Note that we switched to super user. What page/process do you use to search for a policy? If you search by policy number, how do you get the policy information from PolicyCenter to BillingCenter?  What if the policy isn’t already in BillingCenter when you search for it (there may be queue problems in Guidewire)?
• … skipped steps
• Given the current date is the first invoice due date. How do you get the system to the necessary date?  And what happens if it is not already on that date?  How can this test be automated or truly considered “end-to-end” if it can’t be completed in a single execution without significant human intervention?
• When the super user runs the Invoice Due batch job. When batch jobs are run, they can take a long time. Do you wait for them to finish, or come back when they are finished? And if you come back, how do you get back to this step without starting the entire test over?
• … more skipped steps
• Given the current date is the day after the first invoice due date. Yet another date change and more complexity. Remember to consider that multiple tests may require different dates at the same time.
• … and the rest of the steps, you get the idea

As you can see, the lure of Cucumber and Gherkin is in their simplicity, but the implementation and execution of these processes for complex systems like Guidewire can be incredibly challenging. Coupled with the sheer volume of scenarios and data combinations that should be tested, plus integrated third-party applications and legacy systems, you can see why a more purpose-built execution layer is critical to ensure maintainability and functionality when implementing BDD in Guidewire environments.

These concerns are addressed by the CenterTest framework. However, without CenterTest, your team would need to manually address all of these issues to make Gherkin work with Cucumber for Guidewire implementations.

Let’s explore some additional challenges and limitations.

Key Challenges and Limitations:

Tool Integration: Choosing and integrating the tools needed to support your Cucumber layer can be challenging. It may complicate your test stack if you are not careful. CenterTest, on the other hand, greatly simplifies your test stack, and supports most of your automation requirements beyond just Guidewire – using a single tool and programming language.

Gherkin Limitations: Gherkin’s limited expressiveness can lead to overly verbose or simplified test cases. Implementing conditional logic is not straightforward. It is also difficult to extend or override Gherkin ‘steps’ shared across multiple test scripts, resulting in duplication. This further reduces maintainability and scalability. Ultimately, Gherkin test scripts can be cumbersome to maintain as the application evolves.

Support and Maintenance: Cucumber can easily become one of your largest investments around testing when you consider the cost of both implementation and maintenance. These tasks usually fall on your test team, but if that team lacks the required skillset, will you push them to your developers and take them away from development? Will you engage in a long-term managed services contract? In contrast, CenterTest provides a working BDD framework generated directly from your Guidewire source while also making the Gherkin layer optional rather than required.

Our Approach for BDD

While Cucumber and Gherkin offer a structured way to define and automate tests, they can fall short with complex systems. However, CenterTest follows BDD principles in a way that natively supports Guidewire, and allows intricate, comprehensive testing without having to build your own framework.

Consider the following code that was used to generate the earlier Gherkin example. As a reminder, this is an actual test with CenterTest:

Let’s examine some of the benefits of our CenterTest architecture from the perspective of BDD.

1. This code is easy to follow and understand, making it accessible to business stakeholders. It is clear what PC.loginToPC, PC.newPersonAccount, and PC.personalAutoSubmission do.
2. CenterTest enables sophisticated test data management by incorporating OO test data with the PersonalAutoDataCombination.xlsx spreadsheet.
3. You can clearly identify PC functions vs BC functions. CenterTest defines Reusables using the PC.loginToPC structure to make the test easy to understand, to clearly identify which Center is being touched, and to identify that the step in question is part of your reusable library.
4. Reusables with CenterTest come OOTB and are easily and quickly adapted to your implementation because CenterTest’s abstraction layer generates your POMs, product model, typelists, and other elements directly from your Guidewire source code.
5. Notice that Gherkin is unnecessary because communication is inherently provided by the CenterTest Execution Layer through well-named object-oriented reusables.
6. Unlike other tools that provide “end-to-end” testing, CenterTest interacts with Guidewire at the UI level, ensuring true simulation of human interaction when testing.
7. There is built-in support for automated Time Travel and Restart processing to restart tests from their point of failure once the required conditions are met. This is critical, as it emulates true end-to-end processes with as little human intervention in the test as possible.

Specification Layer

CenterTest provides complete end-to-end Guidewire workflows that can be easily extended to match your current implementation, then adapted to new flows for specific requirement changes using any requirements-gathering process.

This works because Guidewire already provides a complete insurance implementation, including policy, claim, and billing support. CenterTest provides a complete set of reusables to support Guidewire OOTB flows that can easily be adapted to your specific needs through object generation directly from your source code.

Gherkin/Cucumber can still be used by Business to define requirements and provide specifications for the test – if desired – but the underlying step definitions and test data are much easier to manage by utilizing our approach to data-driven testing.

Communication Layer

Easily readable reusables, along with robust data-driven test data, provide a comprehensive communication layer without the need for Gherkin. However, CenterTest’s flexibility ensures you can leverage Gherkin if required without compromising the clarity, consistency, and efficiency provided by our reusable components.

Populating data in the spreadsheet provides specification communication. If no data is entered for a specific field, CenterTest simply skips that field when executing the test.

Execution Layer

Prebuilt and generated reusable layers, based on Guidewire flows with components generated directly from Guidewire source, provide a comprehensive execution layer.

Our DDT approach is critical for BDD implementation, as CenterTest’s architecture makes it easy to maintain your tests and test data. Each row in our PersonalAutoDataCombination.xlsx spreadsheet executes a different test, allowing you to execute as many tests as needed to cover all necessary specifications using as few tests as necessary.

Using the above test, business can identify changes to the Submission flow through traditional means or Gherkin, and development can incorporate these changes in both Guidewire and the affected tests. This enhances your entire testing process by allowing automation to be executed, or manual testers to run the automation to specific breakpoints and take over for exploratory or edge case testing.

Value of CenterTest’s Approach to BDD

With CenterTest there is no need to manually build nor maintain the POMs, product model, typelists and supporting helpers needed to enable test automation. CenterTest handles that for you – and you can regenerate these elements as often as necessary to keep up with development changes.

This functionality dramatically increases the speed of BDD and test automation implementation while simultaneously decreasing automation maintenance. Plus, since CenterTest works across all versions of Guidewire, your entire testing framework is future-proofed to minimize refactoring and ensure you never have to rewrite your tests from scratch again.

Finally, the sophistication of testing with CenterTest greatly enhances the scope of what you can accomplish with BDD relative to what is possible with other frameworks.

Can you think of another BDD framework that can provide a single, automated, data-driven, end-to-end Guidewire test that incorporates UI testing, API testing, multiple user roles, automated time travel, and countless other functions?

Narratives – Closing the Loop on BDD

If your organization mandates or prefers providing specifications with Gherkin, wouldn’t they also prefer consuming test output in the same format?

CenterTest Narratives are designed for this specific purpose. Each test execution saves a written flow, providing clear, easily digestible documentation showing business exactly what occurred and allowing them to confirm the test requirements were met. The Narrative can show the actual method names or be formatted to look like Gherkin.

For example, consider Narrative Gherkin output for just the newPersonAccount step, shown below.

This output ensures clarity and accuracy in software testing by detailing every action taken across all UI screens. The detail and drill-down capabilities are automatically generated, even identifying when values are modified from their defaults.

Narratives use CSS stylesheets to adapt their look and feel, making it easy to adapt them to your standards. You can even use a simple property file to produce the output in other languages. Here is the English property file:

Conclusion: Embracing BDD with CenterTest

Behavior-driven development offers a powerful approach to aligning software development with business goals. While it presents challenges, particularly in complex systems, our innovative approaches CenterTest and Narratives can provide powerful solutions that maintain BDD’s core principles while addressing its limitations.

Though it seems that Narratives might bypass collaboration, they actually enhance it. Generating Gherkin-like output from actual test executions provides a concrete basis for discussion. This allows all stakeholders to review and refine the system’s actual behavior, fostering more meaningful and informed collaboration.

By leveraging reusable components, object-oriented test data, data-driven testing, and automatically generated Narratives, CenterTest offers a flexible, efficient, and collaborative approach to BDD.

As the software development landscape evolves, consider adaptive methodologies like CenterTest’s approach to BDD to improve your team’s efficiency, software quality, and alignment with business objectives.

---

Join us for the upcoming articles in our Testing Guidewire blog series, where we will explore the power of POMs with CenterTest for Guidewire, and Everything CenterTest where we will explore our complete solution.

A special thanks to the Kimputing team for their significant 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.