Self Healing and KRE

Product Forums Katalon Studio
1

We are trying out Katalon against an Oracle SAAS implementation, and the idea is we get an Oracle update every quarter on the Friday, we kick the scripts off in our Azure pipeline and come in on the Monday to see what has passed and failed.

However am I right in saying (and I assume this is obvious to most, so be kind) that any self healing aspects of the tool will not work in the pipeline and the scripts will fail if any locator has changed?

1 Like
2

No ,ado pipeline will not disable self healing.

3

Those that were based on neighbourhood-ness, rather than specific objects may continue to work, but it would obviously be based on how “big” a change to the page. What has failed for me consistently is when fields get dropped down another <div> level due to the change.

4

mitigate failures during Oracle SaaS updates:

1. How Self-Healing Works in Katalon

Katalon’s self-healing leverages KRE (Katalon Runtime Engine) and is designed to:

  • Automatically retry failed locators using alternative strategies (e.g., falling back from XPath to CSS or ID).
  • Use Smart Wait to handle dynamic elements and minor UI delays.
  • Adjust locators if the original one fails (e.g., due to attribute changes like id or class).

However, self-healing has limitations in CI/CD pipelines:

  • :cross_mark: It cannot fix major UI changes (e.g., rewritten HTML/CSS after Oracle updates).
  • :cross_mark: It relies on preconfigured fallback locators in the Object Repository. If all locators are invalid, tests fail.
  • :cross_mark: It works best for minor, non-structural changes (e.g., temporary delays, attribute reordering)
    approaches to minimize pipeline failures:

A. Preemptive Maintenance (Before Pipeline Runs)

  • Schedule a “Locator Update Sprint” after Oracle updates:
    1. Run a smoke test suite to detect broken locators.
    2. Use Katalon’s Spy/Record Utility to update locators in the Object Repository.
    3. Commit changes to your version control (e.g., Git) for pipeline reuse.

B. Robust Locator Design

  • Use stable attributes for locators (e.g., data-testid, aria-label, or Oracle-specific metadata).
  • Define multiple fallback locators for critical elements:
// Object Repository Example: Password Field
// Primary: XPath using automationId
// Fallback: CSS using class + attribute
object("PasswordField") {
  "XPath" = "//*[@automationId='txtPassword']"
  "CSS" = ".login-form input[type='password']"
}

C. Programmatic Self-Healing (Advanced)

  • Use Katalon’s onTestFailure() hook in a Test Listener to:
    • Capture failed locators.
    • Retry with dynamic XPath/CSS adjustments (e.g., partial matches).
@Override
void onTestFailure(TestCaseContext testCaseContext) {
  // Retry with alternative locator strategy
  if (testCaseContext.getFailureReason().contains("NoSuchElement")) {
    WebUI.setText(findTestObject("PasswordField", [("css"): ".new-password-selector"]), "your_password")
  }
}

D. Post-Update Automation

  • Trigger a dedicated pipeline job after Oracle updates:
    1. Run Katalon tests in “Dry Run” mode to detect broken locators.
    2. Use Katalon API or CLI commands to export failed tests.
    3. Feed failures into a self-healing script (e.g., regex-based locator adjustments).
5

what a great answer, thank you! Very helpful