Forem: Volta Jebaprashanth

The AI-Native Frontier: Redefining the Future of Quality Engineering

Volta Jebaprashanth — Mon, 02 Mar 2026 06:33:23 +0000

Recently, within the AT + GSC&MS division at Sysco LABS, our Quality Engineering community gathered for an event that felt less like a standard technical conference and more like a bold step into a new reality. QE Spark 2026 was a resounding success — not just as a showcase of cutting-edge technology, but as a declaration of a new strategy designed to fundamentally change how we think about scale, growth, and the role of the modern engineer.

This transformative milestone wouldn’t have been possible without the two pillars of this event: Sujith Thushara, our Senior Manager Quality Engineering and Kasun de Silva, our Architect — Quality Engineering. It was their coordination, leadership, and forward-thinking vision that laid the groundwork for this strategic shift. As a speaker at QE Spark 2026, I was incredibly proud to help bring their vision to life on stage and share our roadmap with an energized, forward-looking community.

Sujith Thushara, Senior Manager Quality Engineering

Kasun de Silva, Architect — Quality Engineering

The Vision: Breaking the Linear Curve

For decades, the technology industry has operated under a predictable, yet limiting, law of physics: as business demand and revenue grow, headcount and operational costs must rise in parallel. This linear model is a hurdle to true innovation and velocity.

The core strategy we unveiled at QE Spark is the creation of a “Growth Delta.” By integrating intelligence into the very fabric of our delivery lifecycle, our goal is to empower business value to soar while keeping our operational footprint lean, agile, and efficient. We are successfully moving away from traditional, effort-based scaling and embracing intelligent growth.

The Journey: From AI-Assisted to AI-Native

A major highlight of the event was outlining our concrete roadmap. We aren’t just talking about the future; we are building it. The transition from legacy methods to an entirely AI-Native ecosystem is broken down into three distinct phases:

Traditional QE

The baseline. This phase is defined by human-driven quality, heavy manual validation, and reactive defect detection.

AI-Assisted QE

Our current state of the art. Here, AI tools actively enhance human effort. We are operating with an automation-first mindset, utilizing tool-enhanced test creation, and driving dramatically faster feedback cycles.

AI-Native QE

The true frontier. This future state moves far beyond mere “assistance” and into a world of Digital Twins, autonomous test evolution, and real-time quality intelligence. In this phase, AI isn’t just a tool; it is a predictive partner that identifies risks and evolves tests before a developer even pushes code.

A Mindset Shift: The Strategic Engineer

One of the most profound takeaways from QE Spark 2026 was that this transformation isn’t just about software — it’s about people. As we move aggressively toward an AI-Native world, the role of the engineer is getting a massive upgrade.

We are successfully breaking the “Regression Bottleneck,” where engineers historically spent half their time executing tests simply because those tests existed. Instead, the future Sysco Labs engineer is a systems thinker and a quality strategist. We are shifting from merely coordinating tests to reviewing intelligent decisions, architecting solutions, and validating complex business logic.

The Engine Room: A Collective Force of Builders

While the vision set on stage was ambitious, the most exciting part of this transformation is what is happening off stage. This isn’t just a top-down mandate; it is a grassroots revolution driven by our entire engineering team.

Our people are in the trenches right now, turning this AI-Native vision into a tangible reality. Across the floor, teams are deeply immersed in hands-on experimentation. We are spinning up rapid prototypes, stress-testing intelligent agents, and deploying cutting-edge Proofs of Concept that challenge the status quo of Quality Engineering. There is an electric culture of innovation taking hold, where every engineer is empowered to become a builder and a disruptor. We aren’t just waiting for the future of QE to arrive — we are actively coding it into existence today.

Looking Ahead

The overwhelming success of QE Spark 2026 was rooted in its clarity of purpose. By shifting from reactive detection to intelligent prevention, our team is actively clearing the path for a future where quality is a continuous, autonomous stream rather than a late-cycle hurdle.

As the event concluded, the atmosphere was electric. We are no longer just asking, “How can we test this?” We are asking, “How can we do this smarter?” The journey toward an AI-Native future at Sysco Labs has officially begun, and the results promise to redefine the very boundaries of Quality Engineering.

Tharushika Rathnayake, Sachini Karunarathne, Nuwanga Arambawela, Tharindu Dias, Dinithra Thantilage, Pasan Somarathna, Iresha Wijesinghe, Thanya Withanachchi, Shanaz Nabeel, Chiran Govinnage, Akila Rangalla, Mohamed Yaseen, Sujith Thushera, Kasun De Silva, Ruzaik Refai, Dineth Mendis, Volta Jebaprashanth.

Raw XPath is Dead: How XPathy's Fluent API Solves Your Flaky Test Problem

Volta Jebaprashanth — Fri, 17 Oct 2025 18:53:19 +0000

One of the most frequent causes of flaky tests is when a front-end change inadvertently alters the casing or spacing of an HTML attribute or text content. A CSS class might change from active to Active, or an error message might gain an extra space: " Error Message " vs. "Error Message". These minor variations are enough to break an exact-match XPath, leading to frustrating test failures.

XPathy's Value Transformation feature provides a fluent, built-in mechanism to address these issues. By applying transformations like case-folding and space-normalization before the locator comparison, XPathy ensures your locators match the intended value, regardless of the developer's formatting choices.

1. Achieving Case-Insensitive Matching

Raw XPath requires the complex use of the translate() function to achieve case-insensitivity. You must provide the entire alphabet twice: once for upper-case characters to replace, and once for the lower-case equivalents to replace them with.

Raw, Error-Prone XPath
`//div[contains(translate(@class, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz'), 'menu-item')]`

XPathy simplifies this into a single, declarative method call using the Case enum.

The `.withCase(IGNORED)` Method

The most common transformation is to ignore case for stable attributes like id or class.

import static com.xpathy.Case.*;

XPathy locator = div.byAttribute(class_)
                    .withCase(IGNORED)
                    .equals("active-tab");

// Result:
//div[translate(@class, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz')='active-tab']

This locator will successfully match elements with class="active-tab", class="Active-Tab", or class="ACTIVE-TAB". This small addition instantly makes the locator bulletproof against casing inconsistencies.

Force Casing (`UPPER` and `LOWER`)

You can also force the element's value to a specific case before comparison, which is helpful for standardizing text content:

XPathy locator = label.byText()
                    .withCase(UPPER)
                    .equals("USERNAME");

// Result:
//label[translate(text(), 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ')='USERNAME']

This ensures the locator matches any variation of "Username," "username," or "USERNAME."

2. Whitespace and Symbol Cleanup

Inconsistent spacing in text nodes is a rampant source of locator flakiness. Similarly, needing to compare numeric values (like prices) often requires removing currency symbols.

Normalize Space with `.withNormalizeSpace()`

The XPath normalize-space() function strips leading and trailing whitespace and replaces sequences of internal whitespace with a single space. XPathy exposes this critical utility directly.

XPathy locator = div.byText()
                    .withNormalizeSpace()
                    .equals("Invalid password");

// Result:
//div[normalize-space(text())='Invalid password']

This locator will match text nodes that contain "Invalid password", " Invalid password ", or even "Invalid password".

Filtering Characters for Consistency

When dealing with dynamic content like prices or order IDs, you often only care about the alphanumeric parts. XPathy allows you to explicitly keep or remove sets of characters.

Scenario	XPathy Code	Function
Numeric Value Check	`span.byText().withRemoveOnly(SPECIAL_CHARACTERS).contains("1999")`	Removes `$` or `,` to stabilize price comparison.
ID Clean-up	`td.byText().withKeepOnly(ENGLISH_ALPHABETS, NUMBERS).equals("ORD123")`	Removes hyphens or spaces from Order IDs like `ORD-123` before checking.

These transformations allow you to focus on the meaningful data rather than the superficial presentation or formatting characters, making the locator invariant to regional currency or spacing differences.

3. Combining Transformations for Ultimate Resilience

The true power of XPathy lies in chaining these operations to clean up a value thoroughly before comparison.

Imagine a product title that might have inconsistent spacing, numbers (which should be ignored), and mixed casing.

XPathy locator = div.byText()
                    .withNormalizeSpace()
                    .withRemoveOnly(NUMBERS)
                    .withCase(IGNORED)
                    .contains("premium feature");

// Result:
//div[contains(translate(translate(normalize-space(text()), '0123456789', ''), 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz'), 'premium feature')]

By stacking .withNormalizeSpace(), .withRemoveOnly(), and .withCase(), the XPath is comprehensively cleaned up. The final result is a locator that will reliably find the element, regardless of how many formatting inconsistencies are introduced by the UI layer.

These fluent transformations are the key to building locators that are truly bulletproof against the casing, spacing, and formatting issues that plague Selenium test stability.

XPathy provides a lot more: Read the Full Documentation:

https://dev.to/volta_jebaprashanth_ac7af/xpathy-a-fluent-api-for-writing-smarter-cleaner-xpath-in-selenium-5753

The Repository:

https://github.com/Volta-Jebaprashanth/xpathy

Happy Testing! 🚀

Stop Writing Flaky Selenium Tests: meet XPathy - The Java Library That Fixes XPath Complexity

Volta Jebaprashanth — Fri, 17 Oct 2025 18:45:45 +0000

Flaky Selenium tests are the bane of every automation team. They waste time, erode trust in the test suite, and slow down deployment cycles. While numerous factors contribute to flakiness—timing issues, synchronization, and race conditions—a major, often overlooked source is the brittleness of hand-written XPath locators.

When an XPath locator is a fragile string full of hardcoded values, quotes, and complex functions, it breaks every time a front-end developer makes a minor change: a class name capitalization, an extra space, or a slightly different attribute value.

XPathy is the Java library built to eliminate this specific complexity and brittleness. By replacing error-prone string concatenation with a fluent, object-oriented API, XPathy lets you define resilient locators that are immediately more stable, reducing the most common causes of XPath-induced flakiness.

1. The Flakiness Pain Point: Brittleness in Raw Locators

A locator is flaky if it works one moment and fails the next without a logical cause. This often stems from developers failing to account for three common, real-world variations:

Flakiness Cause	XPathy Solution	Example of Brittleness
Case Variation	Transformations	Class changes from `active` to `Active`.
Whitespace/Symbols	Transformations	Text changes from `"Total $100"` to `"Total €100.00"`.
Structural Changes	Logical Grouping & Having	A container element shifts position or gets a new, temporary class.

XPathy tackles these issues by embedding robustness and explicit structural validation directly into the locator's construction process.

2. Eliminate Flakiness with Resilient Transformations

The most immediate fix for flakiness is ensuring your locator is immune to minor text and attribute variations. XPathy’s value transformation methods (.with...()) handle this automatically, translating into complex-but-correct XPath functions (like translate() and normalize-space()) under the hood.

A. Case-Insensitivity (Flakiness Fixed)

Instead of relying on a string matching exact capitalization, force the comparison to ignore case.

Flaky Manual XPath	Resilient XPathy Code
`//div[@class='ActiveButton']`	`div.byAttribute(class_).withCase(IGNORED).equals("activebutton")`
Fix: Matches `ActiveButton`, `activebutton`, or `ACTIVEBUTTON` consistently.	output : `"//div[translate(@class, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz')='activebutton']"`

B. White Space and Symbol Neutralization

Prices and error messages frequently contain inconsistent spacing or varying currency symbols, leading to failures.

Flaky Manual XPath	Resilient XPathy Code
`//span[text()='$1,999']`	`span.byText().withRemoveOnly(SPECIAL_CHARACTERS).equals("1999")`
Fix: Removes all symbols and allows the locator to match `$1,999`, `€1.999`, or `1999` based on the stable numeric value.	output : `"//span[translate(text(), concat('!@#$%^&*()_+-=[]{};:,./<>?~\ , '"',"'"), '') = '1999']"`

3. Reduce False Positives with Structural Validation

Flakiness also occurs when a locator accidentally targets the wrong element because its properties (like a class or ID) are reused elsewhere. XPathy’s Having Operations (Section H) allow you to ensure the target element exists only within a validated structure.

You don't just find a button; you find a button that is guaranteed to be inside the active form.

Example: Validating a Target's Context

We want to click the "Submit" button, but only if it belongs to a form that is currently visible (e.g., section#active-form).

XPathy locator = button.byText().equals("Submit").and()
                    .byHaving().ancestor(
                        section.byAttribute(id).equals("active-form")
                    );

// Generated XPath: "//button[text() = 'Submit' and ( ancestor::section[@id='active-form'] )]"

Impact on Flakiness: If a hidden or stale "Submit" button exists outside #active-form, this test will not find it. The locator explicitly restricts the search space, drastically reducing false positives and test flakiness caused by interacting with the wrong element.

4. Maintenance and Clarity: The Ultimate Flakiness Prevention

A major reason XPath locators become brittle is that they are so difficult to read and maintain. When a developer can't quickly understand a complex string, they usually won't fix it properly—they'll just write a new, equally brittle one.

XPathy's fluent API makes locators self-documenting, ensuring that when the UI changes, the corresponding locator fix is obvious:

Broken Code Example	XPathy Fix Example
Old: `//a[@href="/profile" and @class="active"]`	Change to: `a.byAttribute(href).contains("profile").and().byAttribute(class_).contains("selected")`

Benefit: You change .equals("active") to .contains("selected") directly, preserving the logical structure and preventing accidental syntax errors common in raw string edits. |

By promoting clarity, XPathy enforces good practices, leading to a test suite where locators are consistently well-written, structurally sound, and inherently less prone to failure. If you want to stop writing flaky tests, the first step is to upgrade your locator language.

XPathy provides a lot more: Read the Full Documentation:

https://dev.to/volta_jebaprashanth_ac7af/xpathy-a-fluent-api-for-writing-smarter-cleaner-xpath-in-selenium-5753

The Repository:

https://github.com/Volta-Jebaprashanth/xpathy

Happy Testing! 🚀

Meet XPathy: The Fluent Java API That Makes Raw XPath Obsolete

Volta Jebaprashanth — Fri, 17 Oct 2025 18:31:33 +0000

For years, UI automation engineers have struggled with the same nemesis: raw XPath strings. They're brittle, hard to read, and prone to silent errors caused by a misplaced bracket, quote, or function. Balancing string concatenation, single quotes, and double quotes to build complex locators is a maintenance headache that slows down test development and makes debugging a nightmare.

XPathy is a lightweight Java library built to solve this problem. It replaces manual string manipulation with a fluent, object-oriented API, allowing developers to build sophisticated Selenium locators using clear, chainable methods. XPathy makes raw XPath obsolete by turning the process of locator creation into a declarative, business-readable task.

Why XPathy? The Core Problem Solved

The goal of a locator is to express a test's intent. Instead of writing the syntax for an element with an ID that starts with menu-, XPathy lets you express the intent directly:

Traditional, Brittle XPath	XPathy Fluent API (Declarative Intent)
`//div[starts-with(@data-testid, 'menu-') and contains(text(), 'Item')]`	`div.byAttribute(data_testid).startsWith("menu-").and().byText().contains("Item")`

The result is a locator that is dramatically more readable, maintainable, and scalable across different environments. The final XPathy object seamlessly converts to a Selenium By object or a standard XPath string via .getLocator() or .toString().

The XPathy Architecture: Context and Flow

XPathy operates on a clear, layered architecture that guarantees valid XPath generation at every step. This context-building flow is what enables the fluent API.

Starting Point: Begin with a generic attribute (id, class_, data_testid) or a specific HTML tag (div, button, span).
Context Selection: Use a by...() method to define what you are filtering on: .byAttribute(id).byText().byNumber().byStyle(backgroundColor)
Condition Finalization: Apply the final predicate to generate the XPath condition: .equals("value") .contains("text") .greaterThan(50)

1. Basic Operations

All standard XPath operations are immediately accessible:

XPathy Code	Generated XPath	Function
`id.contains("login")`	`//*[contains(@id, 'login')]`	Target any tag with an ID containing "login".
`h2.byText().startsWith("Chapter")`	`//h2[starts-with(text(), 'Chapter')]`	Target an `<h2>` tag whose text begins with "Chapter".
`value.lessThan(50)`	`//*[@value < 50]`	Target any tag where the numeric attribute value is less than 50.

2. Robustness Through Value Transformations

One of XPathy's most powerful features is its ability to apply transformations (like case-insensitivity or whitespace cleanup) before comparison. This creates locators resilient to UI variations.

You use the .with...() methods to apply transformations to the current context:

Scenario	XPathy Code	Function
Ignore Case	`div.byAttribute(class_).withCase(IGNORED).equals("active")`	Matches `class="active"`, `class="Active"`, or `class="ACTIVE"`.
Normalize Space	`p.byText().withNormalizeSpace().equals("Error message")`	Ignores leading/trailing/extra spaces in the text node.
Remove Symbols	`span.byText().withRemoveOnly(SPECIAL_CHARACTERS).contains("1999")`	Removes `$`, `€`, `,`, or `.` from price text before comparison.

These transformations—complex in raw XPath—become simple, chainable methods in XPathy.

3. Logical Composition and Grouping

XPathy eliminates the risk of incorrect operator precedence by managing parentheses automatically when grouping conditions.

Feature	XPathy Example	Generated XPath
Simple AND	`div.byAttribute(id).equals("form").and().byText().contains("Login")`	`//div[@id='form' and contains(text(), 'Login')]`
Union (OR Group)	`button.byAttribute(id).union(Or.equals("btn1"), Or.equals("btn2"))`	`//button[@id='btn1' or @id='btn2']`
Nested Logic	`div.byCondition(and(text()..., or(attr()...)))`	Generates fully parenthesized complex logic.

This fluent logical API enables modeling of complex business rules (e.g., Must be a featured product OR a high-rated product, BUT NOT expired) in clear Java code.

4. Advanced Relationship Testing with Having

The Having Operation allows you to filter a target element based on related elements (child, ancestor, or sibling) without leaving the target context.

Use Case	XPathy Code	Generated XPath
Check Descendant	`div.byAttribute(class_).equals("card").and().byHaving().descendant(span.byText().contains("In Stock"))`	`//div[@class='card' and (.//span[contains(text(), 'In Stock')])]`
Check Preceding Sibling	`input.byAttribute(name).equals("user").and().byHaving().precedingSibling(label.byText().equals("Username"))`	`//input[@name='user' and (preceding-sibling::label[text()='Username'])]`

This allows you to say: "Find the DIV only if it has a descendant SPAN that says 'In Stock'." It's essential for locating containers based on dynamic content.

Conclusion

XPathy is more than just a convenience wrapper; it's a paradigm shift in how web element locators are created. By moving from fragile string-based syntax to a resilient, object-oriented, fluent API, XPathy ensures locators are:

Clear: Intent is expressed explicitly.
Robust: Built-in transformations neutralize common UI quirks.
Maintainable: Code is self-documenting and easy to update.

If your team struggles with flaky tests, complex XPath, and slow debugging cycles, XPathy offers a definitive Java-native solution that makes raw XPath truly obsolete.

XPathy provides a lot more: Read the Full Documentation:

https://dev.to/volta_jebaprashanth_ac7af/xpathy-a-fluent-api-for-writing-smarter-cleaner-xpath-in-selenium-5753

The Repository:

https://github.com/Volta-Jebaprashanth/xpathy

Happy Testing! 🚀

Beyond Parent/Child: Navigating the DOM Tree Fluently with XPathy

Volta Jebaprashanth — Fri, 17 Oct 2025 18:14:11 +0000

The challenge in robust UI automation often lies in locating an element based not just on its own attributes, but on the characteristics of its related nodes — siblings, ancestors, or descendants. Traditional XPath forces context switching (/../following-sibling::*), leading to brittle, unreadable locators.

XPathy addresses this by separating DOM Traversal from Relationship Predication. This article explores how XPathy combines explicit DOM Navigation methods ($up(), $descendant(), etc.) with the powerful, context-preserving Having Operations (byHaving()) to create readable, maintainable, and precisely targeted locators.

1. Foundation: Explicit DOM Traversal

XPathy simplifies the core XPath axes into intuitive, chained methods prefixed with $ for visual clarity. These methods are designed to change the context of the expression, moving from one node to another.

XPathy Method	XPath Axis/Shorthand	Function
`$parent()` / `$up(n)`	`parent::* / ..`	Moves up one or more levels.
`$ancestor(tag)`	`ancestor::tag`	Matches any element above the current node.
`$child(tag)`	`child::tag / ./tag`	Matches immediate children.
`$descendant(tag)`	`descendant::tag / //tag`	Matches elements anywhere below the current node.
`$followingSibling(tag)`	`following-sibling::tag`	Matches elements after the current node at the same level.
`$precedingSibling(tag)`	`preceding-sibling::tag`	Matches elements before the current node at the same level.

Example: Chaining Traversal

XPathy locator = div.byAttribute(id).equals("main")
                  .$parent()
                  .$followingSibling(div)
                  .$descendant(span)
                  .byText().contains("Discount");

Result:

"//div[@id='main']/../following-sibling::div/descendant::span[contains(text(), 'Discount')]"

Purpose: Start at div#main, go up one parent, then across to the next sibling div, and finally find any span below it.

2. Advanced Relationship Predication: Having Operations

While traversal changes context, Having Operations use traversal axes to check an attribute, text, or characteristic of a related node — without changing the locator's final target.

The byHaving() method acts as a predicate (a filter [ ... ]) that encapsulates a relationship test. This is essential when verifying a structural or data-driven relationship before acting on the target element.

A. Checking for a Descendant's Existence (Deep Check)

A common case is locating a container only if it holds a specific button or status message deep within.

Scenario: Find div.card that contains a descendant button with text "Add to Cart".

div.byAttribute(class_).equals("card")
   .and()
   .byHaving().descendant(button.byText().equals("Add to Cart"));

Resulting XPath:

"//div[@class='card' and ( .//button[text() = 'Add to Cart'] )]"

Benefit: The final locator targets the outer div, ensuring WebDriver interacts with the correct container.

B. Checking an Ancestor's Attribute (Context Check)

Ensure that a target element is rendered within the correct structural context — a critical safeguard against false positives.

Scenario: Find a span.price only if its ancestor <section> has id="featured-product".

span.byAttribute(class_).equals("price")
    .and()
    .byHaving().ancestor(section.byAttribute(id).equals("featured-product"));

Resulting XPath:

"//span[@class='price' and ( ancestor::section[@id='featured-product'] )]"

Benefit: If another span.price exists outside the featured section, it’s ignored, ensuring accuracy.

C. Checking a Sibling's Content (Relational Data Check)

Use this when elements depend on their immediate neighbors (e.g., a label followed by an input field).

Scenario: Find an input field preceded by a label with text "Email".

input.byAttribute(type).equals("text")
     .and()
     .byHaving().precedingSibling(label.byText().equals("Email"));

Resulting XPath:

"//input[@type='text' and ( preceding-sibling::label[text() = 'Email'] )]"

Benefit: Precisely target the input using the label text — a stable reference for UI automation.

3. The Power of Composition: Traversal and Having Combined

XPathy allows Traversal and Having to be mixed with logical operators and transformations, unlocking advanced, human-readable locators.

Use Case: Find a div.form-container that contains an enabled Login button.

XPathy locator = div.byAttribute(class_).equals("form-container")
                    .and()
                    .byHaving().descendant(
                        button.byText().contains("Login")
                              .and()
                              .byAttribute(class_).not().contains("disabled")
                    );

Resulting XPath:

"//div[@class='form-container' and ( .//button[contains(text(), 'Login') and not(contains(@class, 'disabled'))] )]"

Explanation: The locator targets the main form container while verifying that it contains a Login button that is not disabled.

Final Thoughts

By separating context traversal from relationship validation, XPathy empowers testers to write structural assertions directly into locators — reducing fragility and increasing readability.

This approach turns XPath from a brittle string expression into a fluent, logical representation of the DOM’s relationships, making UI automation both expressive and maintainable.

XPathy provides a lot more: Read the Full Documentation:

https://dev.to/volta_jebaprashanth_ac7af/xpathy-a-fluent-api-for-writing-smarter-cleaner-xpath-in-selenium-5753

The Repository:

https://github.com/Volta-Jebaprashanth/xpathy

Happy Testing! 🚀

How We Eliminated 90% of Our Locator Failures Using Value Transformations with XPathy

Volta Jebaprashanth — Thu, 16 Oct 2025 18:52:31 +0000

The promise of automated testing is speed and reliability. The reality, however, often involves staring at a CI pipeline failure caused by a tiny, heartbreaking UI change — a change that turns "Submit Button" into "submit button".

This minor inconsistency is the source of endless locator flakiness. Our team realized that the problem wasn’t the XPath syntax itself — it was the fragile, exact-match relationship between our code and the messy, dynamic reality of the browser’s DOM.

By implementing Value Transformations using the Java library XPathy, we stopped fighting minor UI changes and started building resilient locators. The result? A measured 90% reduction in locator-related pipeline failures over three months.

Here’s how we achieved that transformation.

1. The Real Enemy: Dynamic Noise

Most locator failures aren't caused by a complete restructuring of the HTML; they’re caused by “noise”:

Case Inconsistency: New York vs NEW YORK
Unwanted Whitespace: Extra spaces, tabs, or newlines in text content — e.g., " Log In "
Formatting Characters: Currency symbols, commas, or parentheses in numeric values — e.g., ($1,234.56)

Traditional XPath solutions require manually embedding complex functions like translate() or normalize-space(), making locators unreadable and still prone to string errors.

2. The Transformation Toolkit

XPathy replaces manual function transcription with declarative, fluent methods. These automatically wrap your target value in robust XPath code, normalizing the element’s content before comparison.

A. Case-Agnostic Comparison

We stopped worrying about whether a button’s text was capitalized. This immediately fixed all failures related to localization and internal styling changes.

Traditional, Brittle XPath	XPathy, Resilient Code
`//button[text()='Login']`	`button.byText().withCase(IGNORED).equals("login")`

Resulting Robust XPath:

//button[translate(text(), 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz')='login']

B. Whitespace Normalization

Whitespace is the silent killer. Dynamic content often carries unintended leading or trailing spaces. The .withNormalizeSpace() transformation ensures only meaningful characters are compared.

// Stops a test from failing if the text is "  Order Confirmed  "
XPathy locator = div.byText().withNormalizeSpace().equals("Order Confirmed");

Resulting Robust XPath:

//div[normalize-space(text())='Order Confirmed']

C. Filtering Out the Noise

When validating numeric values (prices, scores, counts), you often need to ignore symbols and formatting. XPathy lets you remove characters before comparison.


// Check a price div that might contain "$1,999.00"
XPathy locator = div.byAttribute(class_).equals("total")
                     .and()
                     .byText().withRemoveOnly(CURRENCY_SYMBOLS, COMMAS).equals("1999.00");

// The result removes '$' and ',' before comparing against the expected value.

3. The Tangible Business Result

By adopting Value Transformations, we shifted our focus from low-value maintenance to high-value feature testing.

✅ 90% Reduction in Locator Flakiness: Tests became stable across environments (staging vs. production) because minor formatting differences no longer broke them.
⚡ Faster Authoring: Engineers stopped researching complex XPath functions and simply declared intent.
🧩 Clearer Code: Fluent syntax like .withCase(IGNORED) instantly communicates intent, simplifying code reviews and onboarding.

XPathy provides a lot more: Read the Full Documentation:

https://dev.to/volta_jebaprashanth_ac7af/xpathy-a-fluent-api-for-writing-smarter-cleaner-xpath-in-selenium-5753

The Repository:

https://github.com/Volta-Jebaprashanth/xpathy

We discovered that resilience isn’t about avoiding change — it’s about embracing it by making locators immune to tiny, inevitable inconsistencies of web development.

If you’re tired of watching your CI pipeline go red because of a stray space or capitalization difference, it’s time to equip your team with XPathy’s Value Transformations.

Reliability is within reach.

The Automated Tester's Secret Weapon: Build Robust XPaths in Seconds, Not Minutes (With XPathy)

Volta Jebaprashanth — Thu, 16 Oct 2025 18:41:37 +0000

In the world of automated testing, time is currency. Every minute spent debugging a flaky locator is a minute lost on feature development. Traditional XPath, while powerful, is a massive time sink—it forces testers into tedious, manual labor: counting parentheses, transcribing functions, and meticulously checking for case sensitivity.

What if you could cut the locator creation and maintenance time by 80%?

Introducing XPathy, the fluent Java API that transforms XPath from a brittle, time-consuming string exercise into a rapid, declarative coding task. This library is the automated tester's secret weapon for maximizing speed and reliability.

⏱️ Killer Feature 1: The Speed of Fluency

Imagine needing to locate an element that meets three criteria: it’s a specific product card, it's not disabled, and its price is exactly $49.99.

The Time-Consuming Approach (Raw XPath)

Writing this manually requires chaining and operators, potentially using translate() for case insensitivity, and definitely normalize-space() if you expect dynamic text.

//div[@data-type='product' and not(@class='disabled') and contains(normalize-space(.), '49.99')]

Time taken: ~2 minutes (if you're careful).

The Efficient Approach (XPathy)

XPathy allows you to declare your intent instantly. The compiler handles the syntax, the quotes, and the structure.

XPathy locator = div.byAttribute("data-type").equals("product")
                     .and()
                     .byAttribute(class_).not().equals("disabled")
                     .and()
                     .byText().withNormalizeSpace().contains("49.99");

Time taken: ~30 seconds. You code, XPathy compiles.

The result? Rapid authoring that doesn't sacrifice precision or structure.

🛡️ Killer Feature 2: Reliability by Transformation

Flakiness is the ultimate killer of efficiency. A locator that breaks because a value changed from Login to login or because a developer added a space is a waste of time.

XPathy's Transformations solve flakiness at the source, adding bulletproof resilience without any manual XPath syntax.

The Flaky Reality	The XPathy Resilience	Efficiency Gain
Element text has extra spaces (`" Submit "`)	`.withNormalizeSpace()`	No time spent debugging or writing `normalize-space()`.
Attribute value changes case (`"Enabled"` vs `"enabled"`)	`.withCase(IGNORED)`	No time spent writing long `translate()` functions.
Price text includes currency symbols (`$1,000.00`)	`.withRemoveOnly(SPECIAL_CHARACTERS)`	Instant filtering of noise characters for clean numeric checks.

This isn't just about saving seconds on locator creation; it’s about saving hours on post-release maintenance when the UI changes slightly.

🧠 Killer Feature 3: Precision with Having and Logic

Complex UIs require complex logic. You need to verify not just a single element, but its relationship to others—like finding a table row that contains a cell with a specific status.

In raw XPath, this means switching contexts or using cumbersome relative paths. In XPathy, the Having Operation makes it declarative.

// Find a shopping cart item (div) ONLY if it has a span child that says "Shipped".
XPathy locator = div.byAttribute(class_).equals("cart-item")
                     .and()
                     .byHaving().child(
                         span.byText().equals("Shipped")
                     );

// Result: //div[@class='cart-item' and ( ./span[text()='Shipped'] )]

This fluent chaining allows testers to:

Model Business Logic: Find X if Y exists nearby.
Avoid Fragile Paths: Focus on the condition, not the exact path depth.
Define Complex Groups: Use union() and intersect() to define multiple valid conditions in one go, dramatically reducing the code needed for cross-browser or environmental differences.

🚀 Conclusion: Stop Debugging Strings, Start Automating

The "secret weapon" is simple: use well-designed code to replace manual, error-prone tasks.

XPathy's fluent syntax, intelligent transformations, and powerful logical operators ensure that you are writing robust, readable, and reliable locators in seconds, not minutes.

By focusing on what you need to find instead of how to write the XPath function, you regain valuable time for developing tests, not maintaining locators.

Build smarter, faster, and stronger with XPathy — your automation ally.

From String Soup to Fluent Code: Reinventing XPath in Java with XPathy 🚀

Volta Jebaprashanth — Thu, 16 Oct 2025 18:38:14 +0000

If you’ve spent any time writing UI automation with Selenium and Java, you know the frustration: XPath is brittle, hard to read, and a nightmare to maintain. You spend precious minutes balancing quotes, checking for typos, and debugging flaky locators that break every time a developer changes a single CSS class.

We call this "String Soup"—a mess of long, error-prone strings that hide your automation intent.

But what if you could write locators that look like clean, fluent Java code? What if they could adapt automatically to whitespace, casing, and special characters?

Meet XPathy, a lightweight Java library designed to take the pain out of XPath.

🔍 The Problem: Why XPath Strings Fail Us

Consider a common scenario: you need to find a submit button that has a specific ID but is not currently disabled, and its text should be case-insensitive.

❌ The String Soup XPath

//button[contains(@id, 'submit-') and not(contains(translate(@class, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz'), 'disabled')) and translate(text(), 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz')='login']

This single line is:

Unreadable: Good luck figuring out the logic in six months.
Error-Prone: Missing a quote, forgetting a bracket, or mistyping translate is easy.
Untrustworthy: It relies on complex functions and manual string management.

✅ The Solution: Fluent and Intent-Driven Code

XPathy replaces raw strings with a fluent API that maps human intent directly to XPath logic. Instead of manually writing contains() or translate(), you simply chain methods.

✅ The XPathy Fluent Code

import static com.xpathy.Tag.*;
import static com.xpathy.Attribute.*;
import static com.xpathy.Case.*;

XPathy locator = button.byAttribute(id).contains("submit-")
                        .and()
                        .byAttribute(class_).not().withCase(IGNORED).contains("disabled")
                        .and()
                        .byText().withCase(IGNORED).equals("login");

Result:

//button[contains(@id, 'submit-') and not(contains(translate(@class, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz'), 'disabled')) and translate(text(), 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz')='login']

The code is now:

Readable: It reads like an English sentence.
Type-Safe: The compiler catches typos.
Maintainable: Add or remove conditions without breaking anything.

🔪 Three Pillars of Robust Locators

XPathy solves the three biggest problems with locators: brittleness, complexity, and ambiguity.

1. Bulletproof Locators with Transformations 🛡️

The most common reason for flaky tests is inconsistency in UI values (whitespace, case, or formatting). XPathy’s Transformations automatically wrap your value in the necessary XPath functions.

Flaky Scenario	XPathy Solution	Fluent Code
Case Inconsistency: `Login` vs `LOGIN`	`withCase(IGNORED)`	`byText().withCase(IGNORED).equals("login")`
Whitespace Padding: `" Invalid Password "`	`withNormalizeSpace()`	`byText().withNormalizeSpace().equals("Invalid Password")`
Special Characters: `$1,999.00`	`withRemoveOnly(SPECIAL_CHARACTERS)`	`byText().withRemoveOnly(SPECIAL_CHARACTERS).equals("199900")`
Accents/Diacritics: `Café` vs `Cafe`	`withTranslate()`	`byText().withTranslate("éàè", "eae").contains("Cafe")`

2. Mastering Complex Logic and Precedence 🧠

When a simple .and() isn’t enough, XPathy gives you explicit logical control.

A. Grouping Conditions with Union and Intersect

// Match a button that has one of three possible dynamic IDs
XPathy locator = button.byAttribute(id)
                       .union(
                           Or.equals("login-btn"),
                           Or.equals("signin-btn"),
                           Or.contains("auth-")
                       );

Result:

//button[@id='login-btn' or @id='signin-btn' or contains(@id, 'auth-')]

B. Nested Logic for Precision

import static com.xpathy.Condition.*;

XPathy locator = div.byCondition(
    and(
        text().contains("Order"),
        or(
            attribute(class_).equals("pending"),
            attribute(class_).equals("processing")
        )
    )
);

Result:

//div[contains(text(), 'Order') and (@class='pending' or @class='processing')]

3. DOM Relationships and Having Operations 🔍

Defining relationships in XPath is powerful but hard to read. XPathy simplifies this with byHaving().

// Find a <div> product card that *has* a descendant button with "Add to Cart" text
XPathy locator = div.byAttribute(class_).equals("product-card")
                     .and()
                     .byHaving().descendant(
                         button.byText().contains("Add to Cart")
                     );

Result:

//div[@class='product-card' and ( .//button[contains(text(), 'Add to Cart')] )]

This makes it effortless to filter parent elements based on the content of their descendants.

🚀 From XPathy to Selenium

XPathy integrates directly with Selenium—no extra setup.

Get the Selenium Locator:

By seleniumLocator = xpathy.getLocator();
driver.findElement(seleniumLocator).click();

Get the Raw XPath String (for logging/debugging):

String rawXPath = xpathy.toString();

📊 Conclusion: Stop Writing Strings, Start Writing Code

XPathy is more than a utility—it’s a paradigm shift for locator management. It turns fragile XPath strings into expressive, fluent, and type-safe Java code.

If your tests constantly break because of small UI changes, it’s time to stop debugging String Soup and start building robust, readable, and maintainable locators with XPathy.

Ready to start? Check out the full documentation and repository.

XPathy provides a lot more: Read the Full Documentation:

https://dev.to/volta_jebaprashanth_ac7af/xpathy-a-fluent-api-for-writing-smarter-cleaner-xpath-in-selenium-5753

The Repository:

https://github.com/Volta-Jebaprashanth/xpathy

Happy Testing! 🚀

XPathy: A Fluent API for Writing Smarter, Cleaner XPath in Selenium

Volta Jebaprashanth — Mon, 29 Sep 2025 16:19:26 +0000

XPathy User Manual

XPathy is a lightweight Java library that simplifies the creation of XPath expressions to be used in Selenium. Instead of manually writing long, error‑prone strings, XPathy allows you to build expressions using a fluent API. This makes your locators more readable, maintainable, and scalable. XPathy takes away the frustration of balancing brackets, quotes, and functions, letting developers focus on expressing intent clearly.

When you create an XPathy object, you can call .getLocator() to return a Selenium By object, or call .toString() to get the XPath, making it directly usable in your automation scripts. XPathy is compatible with any Selenium version 3.0 or higher with any Java or Kotlin versions.

Repository

https://github.com/Volta-Jebaprashanth/xpathy

👨‍💻 Author

Created by Volta Jebaprashanth

📧 voltajeba@gmail.com

📞 +94 77 463 7185

🔗 LinkedIn

📦 Package

package com.xpathy;

📦 Installation (via JitPack)

📎 View on JitPack
for other installation modules.

To use this library in your Maven project (pom.xml):

Add the JitPack repository:

<repositories>
  <repository>
    <id>jitpack.io</id>
    <url>https://jitpack.io</url>
  </repository>
</repositories>

Add the XPathy dependency:

<dependencies>
  <dependency>
    <groupId>com.github.Volta-Jebaprashanth</groupId>
    <artifactId>xpathy</artifactId>
    <version>3.0.0</version>
  </dependency>
</dependencies>

A - Basic Operations

This section introduces the basic operations of XPathy with corresponding XPath outputs. By the end of this manual, you will understand how to:

Use attributes (id, class, data-*, etc.)
Work with HTML tags and combine them with attributes
Target text content inside elements
Handle numeric comparisons for attributes and inner text
Query inline style attributes

1. Working with Attributes

Attributes are the most common entry point for XPath locators. XPathy exposes all HTML attributes as objects, each with chainable methods.

Import all attributes:

import static com.xpathy.Attribute.*;

Examples:

Contains on id

XPathy locator = id.contains("login-button");
// Result: //*[contains(@id, 'login-button')]

Equals on class

XPathy locator = class_.equals("active");
// Result: //*[@class='active']

StartsWith on data-testid

XPathy locator = data_testid.startsWith("menu-");
// Result: //*[starts-with(@data-testid, 'menu-')]

Numeric comparisons on value

XPathy locator = value.greaterThan(100);
// Result: //*[@value > 100]

XPathy locator = value.lessThan(50);
// Result: //*[@value < 50]

Additional methods include:

haveIt() → checks whether an attribute exists
isEmpty() → confirms an attribute is present but empty
isNumeric() → ensures an attribute’s value is numeric

2. Attributes within Specific Tags

XPathy allows scoping attributes inside specific HTML tags, making locators more precise.

Import all tags:

import static com.xpathy.Tag.*;

Examples:

Find a <div> by id

XPathy locator = div.byAttribute(id).equals("main-container");
// Result: //div[@id='main-container']

Find a <h2> by class

XPathy locator = h2.byAttribute(class_).equals("section-title");
// Result: //h2[@class='section-title']

Find a <p> by data-testid starting with text

XPathy locator = p.byAttribute(data_testid).startsWith("paragraph-");
// Result: //p[starts-with(@data-testid, 'paragraph-')]

Note: Every attribute method (equals, contains, startsWith, greaterThan, etc.) works with every supported tag.

3. Working with Text Content

XPathy provides intuitive methods for targeting visible text inside elements.

Text contains

XPathy locator = div.byText().contains("Welcome");
// Result: //div[contains(text(), 'Welcome')]

Text starts with

XPathy locator = h2.byText().startsWith("Chapter");
// Result: //h2[starts-with(text(), 'Chapter')]

Global Text usage

XPathy locator = Text.contains("Error");
// Result: //*[contains(text(), 'Error')]

XPathy locator = Text.startsWith("Success");
// Result: //*[starts-with(text(), 'Success')]

This is useful when attributes are dynamic but the element text is stable.

4. Numeric Values Inside Elements

Some elements display numbers, such as counters or prices. XPathy lets you build conditions around them.

Greater than numeric content

XPathy locator = td.byNumber().greaterThan(10);
// Result: //td[number(text()) > 10]

Between numeric values

XPathy locator = span.byNumber().between(5, 15);
// Result: //span[number(text()) >= 5 and number(text()) <= 15]

This is especially handy for table cells or statistic widgets.

5. Working with Styles

Inline styles can be targeted when attributes or text are insufficient.

Check inline style for background colour within a tag

XPathy locator = div.byStyle(backgroundColor).equals("#000000");
// Result: //div[contains(translate(@style, ' ', ''), 'background-color:#000000;')]

Check inline style directly

import static com.xpathy.Style.*;

XPathy locator = backgroundColor.equals("#000000");
// Result: //*[contains(translate(@style, ' ', ''), 'background-color:#000000;')]

B - Understanding the Architecture Flow

XPathy follows a layered architecture for building locators. Each starting point such as .byText(), .byAttribute(), .byNumber(), or .byStyle() returns a builder object that knows how to handle that context:

.byText() → switches context to element text, allowing operations like .equals(), .contains(), .startsWith().
.byAttribute(attribute) → switches context to a specific attribute, enabling methods such as .equals(), .contains(), .startsWith(), .greaterThan(), .lessThan().
.byNumber() → converts inner text into a number, making numeric methods like .greaterThan(), .lessThan(), .between() available.
.byStyle(styleAttribute) → inspects inline CSS properties inside the style attribute, and supports .equals(), .haveIt().

How methods are chained

When you call .equals(), .contains(), .startsWith(), etc., you are finalizing the condition on the selected context. For example:

XPathy locator = div.byAttribute(id).equals("header");

Flow:

div sets the base tag.
.byAttribute(id) selects the id attribute.
.equals("header") finalizes the expression as //div[@id='header'].

Similarly:

XPathy locator = h2.byText().startsWith("Title");

Flow:

h2 sets the base tag.
.byText() switches to the text node.
.startsWith("Title") produces //h2[starts-with(text(),'Title')].

This consistent flow applies to all contexts. You always begin with a tag or attribute, select the context with .byText(), .byAttribute(), .byNumber(), or .byStyle(), then finalize with methods like .equals(), .contains(), .startsWith(), .greaterThan(), or .between(). The resulting XPathy object can then be converted to a Selenium By object with .getLocator().

C - Basic Logical Operations

XPathy also supports combining multiple conditions with logical operators. These map directly to XPath and(), or(), and not() constructs, but with a fluent, chainable API that preserves readability.

Logical operations can be applied between different contexts (attributes, text, numbers, styles), making it possible to express powerful compound locators without juggling parentheses and syntax manually.

1. `and()`

The .and() operator joins two conditions that must both be true.

XPathy locator = div.byAttribute(id).equals("main-container")
                    .and()
                    .byText().contains("Hello World");

// Result: //div[@id='main-container' and contains(text(), 'Hello World')]

Explanation:

div.byAttribute(id).equals("main-container") → //div[@id='main-container']
.and().byText().contains("Hello World") → adds an additional condition on the same div node.
Final → //div[@id='main-container' and contains(text(), 'Hello World')]

2. `or()`

The .or() operator joins two conditions where either one may be true.

XPathy locator = div.byAttribute(id).equals("main-container")
                    .or()
                    .byText().contains("Hello World");

// Result: //div[@id='main-container' or contains(text(), 'Hello World')]

Explanation:

Matches any <div> with id="main-container" OR text containing "Hello World".

3. `not()`

The .not() operator negates the following condition. This allows you to exclude elements matching a certain attribute, text, or style.

XPathy locator = div.byText().contains("Hello World")
                    .and()
                    .byAttribute(id).not().equals("main-container");

// Result: //div[contains(text(), 'Hello World') and not(@id='main-container')]

Explanation:

First condition: contains(text(), 'Hello World')
Second condition: not(@id='main-container')
Combined with .and() → //div[contains(text(), 'Hello World') and not(@id='main-container')]

4. Chaining Multiple Logical Operations

XPathy allows chaining and(), or(), and not() in sequence to build more complex predicates.

XPathy locator = span.byText().contains("Discount")
                     .and()
                     .byAttribute(class_).not().equals("expired")
                     .or()
                     .byNumber().greaterThan(50);
// Result:
//span[contains(text(), 'Discount') and not(@class='expired') or number(text()) > 50]

Usage Tips:

Parentheses are automatically handled to preserve correct evaluation order.
You can mix attribute, text, number, and style conditions freely.
Use .not() immediately before .equals(), .contains(), .startsWith(), etc.

✅ With logical operators, XPathy expressions scale from simple attribute checks to full-fledged business rules written in a clear, fluent style.

D - DOM Navigation

XPathy provides intuitive methods for navigating the DOM tree. These methods allow you to traverse relationships between elements—moving up, down, or sideways—while still chaining into text, attributes, numbers, or styles.

All navigation methods starts with $ made you easy to extend it with a traversal operator such as $child(), $parent(), $ancestor(), $descendant(), $followingSibling(), or $precedingSibling().

1. `$tag(tag)`

Targets a nested tag under the current element.

XPathy locator = div.byAttribute(class_).equals("container")
                .$tag(button)
                .byText().equals("Submit");

//Result:
//div[@class='container']//button[text()='Submit']

2. `$child()`

Restricts traversal to immediate child elements.

XPathy locator = ul.byAttribute(id).equals("menu")
                .$child()
                .byText().contains("Home");
//Result:
//ul[@id='menu']/child::*[contains(text(), 'Home')]


// Specific child tag
XPathy locator = ul.byAttribute(id).equals("menu")
                .$child(li)
                .byText().contains("Contact");

//Result:
//ul[@id='menu']/child::li[contains(text(), 'Contact')]

3. `$ancestor()`

Moves upward in the DOM to match ancestor elements.

XPathy locator = a.byAttribute(href).contains("profile")
                .$ancestor()
                .byAttribute(id).equals("navbar");
//Result:
//a[contains(@href, 'profile')]/ancestor::*[@id='navbar']


// Specific ancestor tag
XPathy locator = span.byText().equals("Settings")
                .$ancestor(div)
                .byAttribute(class_).equals("dropdown");

//Result:
//span[text()='Settings']/ancestor::div[@class='dropdown']

4. `$descendant()`

Matches descendant elements nested anywhere below the current node.

XPathy locator = section.byAttribute(id).equals("content")
                .$descendant(p)
                .byText().contains("Welcome");

//Result:
//section[@id='content']/descendant::p[contains(text(), 'Welcome')]


// Any descendant
XPathy locator = div.byAttribute(class_).equals("card")
                .$descendant()
                .byAttribute(class_).equals("price");

//Result:
//div[@class='card']/descendant::*[@class='price']

5. `$parent()` and `$up()`

Navigate one or more levels up the DOM.

XPathy locator = span.byText().equals("$19.99")
                .$parent(div)
                .byAttribute(class_).equals("product");

//Result:
//span[text()='$19.99']/parent::div[@class='product']


// Move up multiple levels
XPathy locator = input.byAttribute(name).equals("email")
                .$up(2)
                .byAttribute(id).equals("form-container");

//Result:
//input[@name='email']/../..[@id='form-container']

6. `$followingSibling()`

Matches siblings that appear after the current element.

XPathy locator = label.byText().equals("Username")
                .$followingSibling(input)
                .byAttribute(type).equals("text");

//Result:
//label[text()='Username']/following-sibling::input[@type='text']


// Any following sibling
XPathy locator = h2.byText().equals("Features")
                .$followingSibling()
                .byAttribute(class_).equals("description");

//Result:
//h2[text()='Features']/following-sibling::*[@class='description']

7. `$precedingSibling()`

Matches siblings that appear before the current element.

XPathy locator = li.byText().equals("Contact")
                .$precedingSibling()
                .byText().equals("About");

//Result:
//li[text()='Contact']/preceding-sibling::*[text()='About']


// Specific preceding sibling
XPathy locator = option.byText().equals("Canada")
                .$precedingSibling(option)
                .byText().equals("USA");

//Result:
//option[text()='Canada']/preceding-sibling::option[text()='USA']

8. Multiple Navigations

XPathy also supports chaining multiple navigation steps in sequence to express complex DOM relationships.

XPathy locator = div.byAttribute(id).contains("main-container")
                .$parent()
                .$followingSibling(div)
                .$descendant()
                .byText().contains("Hello World");

//Result:
//div[contains(@id, 'main-container')]/../following-sibling::div/descendant::*[contains(text(), 'Hello World')]

✅ With DOM navigation, XPathy makes parent-child, ancestor-descendant, and sibling relationships explicit, realistic, and chainable using examples drawn from real-world UIs.

E - Value Transformations

One of the most powerful features of XPathy is the ability to transform values before applying conditions. Transformations make locators more robust against variations in casing, whitespace, special characters, numbers, or accented characters.

Transformations are chainable and can be combined in sequence. They apply to the current context (attribute, text, number, or style) before the final predicate (equals, contains, startsWith, etc.) is applied.

1. Case Transformations

Import cases:

import static com.xpathy.Case.*;

Ignore Case

XPathy locator = button.byAttribute(id)
                .withCase(IGNORED)
                .contains("login-button");

//Result:
//button[contains(translate(@id, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz'), 'login-button')]

Description: Useful when the id attribute can appear in different cases (Login-Button, LOGIN-BUTTON, etc.). Without this, you’d have to write multiple OR conditions. This makes the locator simpler and case-proof.

Sample Situation: A login button has dynamic casing depending on the build pipeline. Instead of maintaining different XPaths, this ensures one locator works for all.

Force Uppercase

XPathy locator = label.byText()
                .withCase(UPPER)
                .equals("USERNAME");

//Result:
//label[translate(text(), 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ')='USERNAME']

Description: Normalizes all text to uppercase before comparing. Makes it easy when UI labels are expected to be uppercase, but sometimes come mixed-case.

Sample Situation: A form label might appear as Username, USERNAME, or UserName. With transformation, all variations still match.

Force Lowercase

XPathy locator = div.byAttribute(class_)
                .withCase(LOWER)
                .equals("active");

//Result:
//div[translate(@class, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz')='active']

Description: Ensures attribute comparison works even when class values vary by case. CSS classes are often lowercase, but some dev teams mix formats.

Sample Situation: You’re matching <div class="Active"> vs <div class="active">. This keeps the locator consistent.

2. Whitespace Handling

Normalize Space in Text

XPathy locator = div.byText()
                .withNormalizeSpace()
                .equals("Invalid password");

//Result:
//div[normalize-space(text())='Invalid password']

Description: Cleans up inconsistent spacing inside text content.

Sample Situation: Error messages sometimes appear with odd padding: "Invalid password". This matches regardless of spacing.

3. Character Filtering (Keep or Remove)

Import filters:

import static com.xpathy.Only.*;

Keep Only

You can use one / many Only enums listed in the Only class inside these transformations.

XPathy locator = span.byText()
                .withKeepOnly(ENGLISH_ALPHABETS)
                .contains("ProductABC");

//Result:
//span[contains(translate(text(), translate(text(), 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ', ''), ''), 'ProductABC')]

Description: Strips everything except letters, ignoring numbers or symbols.

Sample Situation: Product titles like Product-ABC should still match when you only care about the alphabetic part.

Keep Only with Multiple `Only` enums

XPathy locator = td.byText()
                .withKeepOnly(ENGLISH_ALPHABETS, NUMBERS)
                .equals("ORD1234");

//Result:
//td[translate(text(), translate(text(), 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789', ''), '')='ORD1234']

Description: Preserves letters and digits, removing symbols or spaces.

Sample Situation: Order IDs sometimes render as ORD-1234 or ORD 1234. This transformation makes them match as ORD1234.

Remove Only

Same as keepOnly() You can use one / many Only enums listed in the Only class inside these transformations.

XPathy locator = span.byText()
                .withRemoveOnly(SPECIAL_CHARACTERS)
                .contains("1999");

//Result:
//span[contains(translate(text(), concat('!@#$%^&*()_+-=[]{}|;:,./<>?`~' , "'", '"'), ''), '1999')]

Description: Eliminates all the symbols

Sample Situation: Prices appear as $1,999 or €1.999. After removing special characters, you can reliably match 1999.

4. Character Translation

XPathy locator = h1.byText()
                .withTranslate("éàè", "eae")
                .contains("Cafe");

//Result:
//h1[contains(translate(text(), 'éàè', 'eae'), 'Cafe')]

Description: Replaces accented letters with plain equivalents.

Sample Situation: The UI shows Café, Cafè, or Càfe. Translating accents ensures all match Cafe.

5. Combining Multiple Transformations

Transformations can be stacked in sequence, and be applied in the order.

XPathy locator = div.byText()
                .withNormalizeSpace()
                .withRemoveOnly(NUMBERS)
                .withTranslate("éàè", "eae")
                .withCase(IGNORED)
                .contains("premium cafe");

//Result:
//div[contains(translate(translate(translate(normalize-space(text()), 'éàè', 'eae'), '0123456789', ''), 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz'), 'premium cafe')]

Description: Cleans text thoroughly by trimming, removing numbers, translating accents, and ignoring case.

Sample Situation: Product title in UI appears as " Prémium Café 2024 " or "PREMIUM CAFE". This locator still matches it reliably.

✅ Transformations are the critical differentiator in XPathy. They eliminate brittle locators by normalizing casing, whitespace, characters, and formatting differences automatically, letting you focus on intent rather than string quirks.

F - Union and Intersect Logical Operations

XPathy goes beyond simple and(), or(), and not() chaining by introducing union and intersect operations. These allow you to group multiple conditions into clean, reusable blocks, improving readability and reducing parenthesis juggling in complex locators.

1. Union (`union(Or...)`)

The union() method combines multiple OR conditions into a single predicate. Instead of chaining multiple .or() calls, you can list them together for clarity.

Example: Multiple Login Button IDs

XPathy locator = button.byAttribute(id)
                    .union(Or.equals("login-btn"),
                           Or.equals("signin-btn"),
                           Or.contains("auth"));

// Result:
//button[@id='login-btn' or @id='signin-btn' or contains(@id, 'auth')]

Description: Matches any <button> used for logging in, regardless of whether the app calls it login-btn, signin-btn, or something dynamic like auth-123.

Sample Situation: Different environments (dev, QA, prod) may use slightly different IDs for the login button. Instead of writing separate locators for each, the union ensures one robust locator works everywhere.

2. Intersect (`intersect(And...)`)

The intersect() method combines multiple AND conditions into one predicate. This is especially useful when you want a field or text to satisfy multiple patterns simultaneously.

Example: Order Confirmation Messages

XPathy locator = div.byText()
                    .intersect(And.startsWith("Order #"),
                              And.contains("Confirmed"),
                              And.not().contains("Cancelled"));

// Result:
//div[starts-with(text(), 'Order #') and contains(text(), 'Confirmed') and not(contains(text(), 'Cancelled'))]

Description: Matches any <div> showing an order confirmation such as Order #1234 Confirmed, but excludes cancelled orders like Order #1234 Cancelled.

Sample Situation: After placing an order, the app shows confirmation text in different formats. Intersect ensures your test only picks valid confirmed orders.

3. Using Transformations with Union and Intersect

Just like with single conditions, you can apply transformations inside union() and intersect(). This makes locators more resilient to variations in casing, spacing, or special characters.

Example: Union with Transformation for Navigation Tabs

XPathy locator = li.byAttribute(class_)
                    .union(Or.withRemoveOnly(SPECIAL_CHARACTERS).contains("active"),
                           Or.withCase(IGNORED).equals("selected"));

// Result:
//li[contains(translate(@class, concat('!@#$%^&*()_+-=[]{}|;:,./<>?`~\' , '"',"'"), ''), 'active') or translate(@class, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz')='selected']

Sample Situation: A navigation tab might render with classes like active!, selected, or SELECTED. With transformations, the locator still works consistently.

Example: Intersect with Transformation for Product Labels

XPathy locator = span.byText()
                    .intersect(And.withNormalizeSpace().contains("Premium"),
                              And.withCase(LOWER).contains("subscription"));

// Result:
//span[contains(normalize-space(text()), 'Premium') and contains(translate(text(), 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz'), 'subscription')]

Sample Situation: Product labels may appear as Premium SUBSCRIPTION, premium subscription, or PREMIUM Subscription. Normalization and case-insensitive comparison ensure all variants match.

✅ With union and intersect, XPathy makes real-world locators—like login buttons, order confirmations, and product labels—clean, robust, and transformation-friendly, while still compiling to pure XPath under the hood.

G - Nested Logical Conditions

XPathy also supports nested logical conditions, allowing you to build deeply structured expressions with combinations of and(), or(), and not(). This makes it possible to represent complex business rules in a way that is both clear and maintainable.

1. How It Works

Instead of chaining and(), or(), and not() inline, you can use the Condition helper methods to group multiple conditions explicitly. This helps when certain expressions need parentheses for precedence.

Import static methods:

import static com.xpathy.Condition.*;

2. Example: Nested Login Validation

XPathy locator = div.byCondition(
                and(
                        text().startsWith("Login"),

                        or(
                                text().contains("Button"),
                                attribute(id).contains("auth-btn")
                        ),

                        not(attribute(class_).withCase(IGNORED).contains("disabled"))
                )
        );

// Result:
//div[(starts-with(text(), 'Login')
//      and (contains(text(), 'Button') or contains(@id, 'auth-btn'))
//      and not(contains(translate(@class, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ','abcdefghijklmnopqrstuvwxyz'), 'disabled')))]

Description:

Must start with the word Login
Must either contain the text Button or have an ID containing auth-btn
Must not contain the class disabled (case-insensitive)

Sample Situation: On a login form, the submit button may appear as Login Button, Login, or even dynamically generated with ID auth-btn-123. Sometimes the button is disabled with disabled class. This nested locator ensures you only match the correct, enabled login button.

3. Example: Product Label with Nested Rules

// Nested Logical Conditions
import static com.xpathy.Condition.*;
XPathy locator = span.byCondition(
                or(
                        text().contains("Premium"),

                        and(
                                attribute(class_).equals("highlight"),
                                attribute(data_testid).contains("featured"),
                                not(text().contains("Expired"))
                        )
                )
        );

// Result:
//span[
//   contains(text(), 'Premium')
//   or (
//       @class='highlight'
//       and contains(@data-testid, 'featured')
//       and not(contains(text(), 'Expired'))
//   )
//]

Description:

Matches <span> elements that either contain the word Premium OR
Have class equal to highlight, a data-testid containing featured, and text that does not contain Expired.

Sample Situation: In an e-commerce site, premium products may be labeled with the word Premium in the text, or tagged structurally with a highlight class and data-testid attribute like featured-product. Expired promotions should be excluded. This nested locator ensures your tests target only valid premium or featured product labels.---

4. Benefits of Nested Conditions

Clarity: Explicit parentheses in code mirror how the XPath will evaluate.
Maintainability: Easy to add or remove conditions without breaking the structure.
Flexibility: Supports mixing attributes, text, styles, and transformations.
Accuracy: Guarantees correct precedence when combining multiple conditions.

✅ With nested logical conditions, XPathy can model real-world business rules like enabled login buttons or valid product labels in a fluent, readable style while generating precise XPath expressions.

H - Having Operations

XPathy introduces Having operations, which allow you to define conditions on related elements (child, parent, ancestor, sibling, etc.) inside the same expression. This eliminates the need to manually switch context, while keeping locators expressive and precise.

The byHaving() method acts as a predicate builder, where you can inject another XPathy object or specify traversal operators like child, descendant, ancestor, etc.

1. Basic Having with Direct Condition

XPathy locator = div.byAttribute(class_).equals("product-card").and()
                .byHaving(
                         span.byText().contains("In Stock")
                         );

// Result:
//div[@class='product-card' and ( span[contains(text(), 'In Stock')] )]

Description: Selects <div class="product-card"> elements only if they contain a <span> with text containing "In Stock".

Sample Situation: Useful when filtering product cards that explicitly show availability labels.

2. Having with Child

XPathy locator = table.byHaving().child(
                  tr.byAttribute(class_).equals("total-row")
                  );

// Result:
//table[( ./tr[@class='total-row'] )]

Description: Matches an <table> if it has a direct child row with the class total-row.

Sample Situation: Ensures the order summary table contains a row summarizing the total.

3. Having with Descendant

XPathy locator = section.byAttribute(id).equals("checkout").and()
                .byHaving().descendant(
                      button.byText().contains("Place Order")
                      );

// Result:
//section[@id='checkout' and ( .//button[contains(text(), 'Place Order')] )]

Description: Matches a <section id="checkout"> if any nested descendant button contains the text "Place Order".

Sample Situation: Ensures the checkout section contains the final purchase button.

4. Having with Ancestor

XPathy locator = div.byAttribute(class_).equals("price-tag").and()
                .byHaving().ancestor(
                       section.byAttribute(id).equals("product-details")
                       );

// Result:
//div[@class='price-tag' and ( ancestor::section[@id='product-details'] )]

Description: Matches <div class="price-tag"> only if it has a <section> ancestor with id="product-details".

Sample Situation: Useful when price elements appear in multiple contexts, but you only want those tied to the product details section.

5. Having with Parent

XPathy locator = ul.byAttribute(class_).equals("menu-items").and()
                .byHaving().parent(
                      nav.byAttribute(role).equals("navigation")
                      );

// Result:
//ul[@class='menu-items' and ( parent::nav[@role='navigation'] )]

Description: Matches <ul class="menu-items"> only if its immediate parent <nav> has the role navigation.

Sample Situation: Ensures you are selecting menu items that belong to the main navigation bar.

6. Having with Following Sibling

XPathy locator = h2.byText().equals("Features").and()
                .byHaving().followingSibling(
                       div.byAttribute(class_).equals("description")
                       );

// Result:
//h2[text()='Features' and ( following-sibling::div[@class='description'] )]

Description: Matches <h2> with text "Features" only if a following sibling div has class description.

Sample Situation: Useful when feature headers are always followed by a descriptive block.

7. Having with Preceding Sibling

XPathy locator = li.byText().equals("Contact").and()
                .byHaving().precedingSibling(
                     li.byText().equals("About")
                     );

// Result:
//li[text()='Contact' and ( preceding-sibling::li[text()='About'] )]

Description: Matches <li> with text "Contact" only if a preceding sibling li contains "About".

Sample Situation: Ensures the navigation order is About → Contact.

8. Having with Simplified workflow

XPathy locator = table.byAttribute(id).equals("invoice").and()
                .byHaving().child(td).byText().contains("Subtotal");

// Result:
//table[@id='invoice' and ./td[contains(text(), 'Subtotal')]]

Description: Matches <table id="invoice"> if it contains a direct <td> child with text "Subtotal".

Sample Situation: Ensures invoices include a subtotal cell before calculating totals.

9. General Benefits

Readability: Express complex DOM relationships inline without writing full XPath manually.
Flexibility: Mix with transformations (withCase, withRemoveOnly, etc.) for resilient conditions.
Reusability: You can insert any XPathy expression into byHaving().

✅ With Having operations, XPathy allows conditions to be written on related elements — child, parent, ancestor, descendant, or siblings — while keeping expressions structured and business-readable.

🎯 Conclusion

XPathy turns brittle, hand-written XPath into a fluent, readable DSL that scales with your UI and your team. From attribute/text/number/style contexts to robust value transformations, DOM navigation, logical composition (and/or/not, union/intersect), nested conditions, and Having operations—everything is designed to express intent clearly while compiling to pure XPath under the hood. The result is faster authoring, easier reviews, fewer flaky locators, and a test suite you can actually trust.

🤝 Contributing

Issues, ideas, and PRs are welcome! Share real-world cases where XPathy simplified your locators, or propose new operators/transformations you’d love to see. Clear repros and before/after snippets help a ton.

💬 Support & Feedback

If something feels clunky or you’ve got a “there must be a nicer way” moment—open an issue. XPathy grows best with practical feedback from active test suites.

🙌 Thanks

Thanks to everyone building reliable UI tests and pushing for clearer, more maintainable code. Your feedback shapes XPathy’s roadmap.

Made with ❤️ by Volta Jebaprashanth

📧 voltajeba@gmail.com
🔗 LinkedIn

Happy Testing with XPathy! 🚀

Mastering Attribute-Based Locators in Selenium with XPathy

Volta Jebaprashanth — Mon, 29 Sep 2025 16:12:52 +0000

When it comes to Selenium automation, locators are everything. If your locators are brittle, your tests will break at the slightest UI change. Among all locator strategies, XPath remains the most powerful—but also the most painful to maintain. Writing //div[@id='login-btn' and contains(@class,'active')] over and over is tedious, error‑prone, and clunky.

This is where XPathy changes the game.

Why Attributes Matter

Most real-world web elements are identified by attributes: id, class, data-testid, role, or custom data attributes. Unfortunately, attribute handling in raw XPath can get verbose:

//button[@id='login-btn' or contains(@class,'primary')]

Now imagine doing this across hundreds of tests. It gets messy, fast.

Enter XPathy: Fluent Attribute Handling

With XPathy, attributes become first-class citizens. Instead of juggling quotes and brackets, you express intent directly:

import static com.xpathy.Attribute.*;
import static com.xpathy.Tag.*;

XPathy locator = button.byAttribute(id).equals("login-btn");
// Result: //button[@id='login-btn']

Want to match by class?

XPathy locator = div.byAttribute(class_).contains("active");
// Result: //div[contains(@class, 'active')]

Need numeric comparisons on attributes like value?

XPathy locator = input.byAttribute(value).greaterThan(100);
// Result: //input[@value > 100]

Suddenly, the code reads like English—no lost time deciphering brackets.

Power Move: Attribute Chaining

Raw XPath forces you to juggle and conditions manually. XPathy makes it natural:

XPathy locator = div.byAttribute(id).equals("main-container")
                     .and()
                     .byAttribute(class_).contains("active");

// Result: //div[@id='main-container' and contains(@class,'active')]

Readable. Scalable. Maintainable.

Real-World Scenario

Let’s say you’re testing an e-commerce site. The “Add to Cart” button can look different depending on environment:

Dev: <button id="add-btn">
QA: <button id="cart-add">
Prod: <button id="add-to-cart">

In plain XPath, you’d either duplicate locators or write a gnarly OR expression. With XPathy:

XPathy locator = button.byAttribute(id)
                       .union(Or.equals("add-btn"),
                              Or.equals("cart-add"),
                              Or.equals("add-to-cart"));

// Result: //button[@id='add-btn' or @id='cart-add' or @id='add-to-cart']

One locator, robust across environments.

Why This Matters

Less Fragile: Avoids hand-crafted strings that collapse on UI tweaks.
More Expressive: Reads like intent, not syntax.
Easier Onboarding: New team members won’t fear XPath anymore.
Future-Proof: Transformations (case-insensitive, whitespace normalization, symbol removal) make locators resilient to messy frontends.

Final Thoughts

If you’re serious about automation, mastering attribute-based locators is a must. XPathy doesn’t replace XPath—it makes it human-friendly. Attributes are no longer a pain point; they’re your strongest ally in building robust, future-proof Selenium tests.

👉 Next up in this series: “Taming Text Nodes: Smarter Content Locators with XPathy” 🚀

Forem: Volta Jebaprashanth

The AI-Native Frontier: Redefining the Future of Quality Engineering

The Vision: Breaking the Linear Curve

The Journey: From AI-Assisted to AI-Native

Traditional QE

AI-Assisted QE

AI-Native QE

A Mindset Shift: The Strategic Engineer

The Engine Room: A Collective Force of Builders

Looking Ahead

Raw XPath is Dead: How XPathy's Fluent API Solves Your Flaky Test Problem

1. Achieving Case-Insensitive Matching

The .withCase(IGNORED) Method

Force Casing (UPPER and LOWER)

2. Whitespace and Symbol Cleanup

Normalize Space with .withNormalizeSpace()

Filtering Characters for Consistency

3. Combining Transformations for Ultimate Resilience

XPathy provides a lot more: Read the Full Documentation:

The Repository:

Stop Writing Flaky Selenium Tests: meet XPathy - The Java Library That Fixes XPath Complexity

1. The Flakiness Pain Point: Brittleness in Raw Locators

2. Eliminate Flakiness with Resilient Transformations

A. Case-Insensitivity (Flakiness Fixed)

B. White Space and Symbol Neutralization

3. Reduce False Positives with Structural Validation

Example: Validating a Target's Context

4. Maintenance and Clarity: The Ultimate Flakiness Prevention

XPathy provides a lot more: Read the Full Documentation:

The Repository:

Meet XPathy: The Fluent Java API That Makes Raw XPath Obsolete

Why XPathy? The Core Problem Solved

The XPathy Architecture: Context and Flow

1. Basic Operations

2. Robustness Through Value Transformations

3. Logical Composition and Grouping

4. Advanced Relationship Testing with Having

Conclusion

XPathy provides a lot more: Read the Full Documentation:

The Repository:

Beyond Parent/Child: Navigating the DOM Tree Fluently with XPathy

1. Foundation: Explicit DOM Traversal

2. Advanced Relationship Predication: Having Operations

A. Checking for a Descendant's Existence (Deep Check)

B. Checking an Ancestor's Attribute (Context Check)

C. Checking a Sibling's Content (Relational Data Check)

3. The Power of Composition: Traversal and Having Combined

Final Thoughts

XPathy provides a lot more: Read the Full Documentation:

The Repository:

How We Eliminated 90% of Our Locator Failures Using Value Transformations with XPathy

1. The Real Enemy: Dynamic Noise

2. The Transformation Toolkit

A. Case-Agnostic Comparison

B. Whitespace Normalization

C. Filtering Out the Noise

3. The Tangible Business Result

XPathy provides a lot more: Read the Full Documentation:

The Repository:

The Automated Tester's Secret Weapon: Build Robust XPaths in Seconds, Not Minutes (With XPathy)

⏱️ Killer Feature 1: The Speed of Fluency

The Time-Consuming Approach (Raw XPath)

The Efficient Approach (XPathy)

🛡️ Killer Feature 2: Reliability by Transformation

🧠 Killer Feature 3: Precision with Having and Logic

🚀 Conclusion: Stop Debugging Strings, Start Automating

From String Soup to Fluent Code: Reinventing XPath in Java with XPathy 🚀

🔍 The Problem: Why XPath Strings Fail Us

❌ The String Soup XPath

✅ The Solution: Fluent and Intent-Driven Code

✅ The XPathy Fluent Code

The code is now:

🔪 Three Pillars of Robust Locators

1. Bulletproof Locators with Transformations 🛡️

2. Mastering Complex Logic and Precedence 🧠

A. Grouping Conditions with Union and Intersect

B. Nested Logic for Precision

3. DOM Relationships and Having Operations 🔍

🚀 From XPathy to Selenium

📊 Conclusion: Stop Writing Strings, Start Writing Code

The `.withCase(IGNORED)` Method

Force Casing (`UPPER` and `LOWER`)

Normalize Space with `.withNormalizeSpace()`

Note: Every attribute method (`equals`, `contains`, `startsWith`, `greaterThan`, etc.) works with every supported tag.

1. `and()`

2. `or()`

3. `not()`

1. `$tag(tag)`

2. `$child()`

3. `$ancestor()`

4. `$descendant()`

5. `$parent()` and `$up()`

6. `$followingSibling()`

7. `$precedingSibling()`

Keep Only with Multiple `Only` enums

1. Union (`union(Or...)`)

2. Intersect (`intersect(And...)`)