🎯 Locator Mastery (Heart of the Page)

Locator Mastery (Heart of the Page): This group is the HEART of the page: everything you learned in groups A-G (DOM, HTML, CSS, JS, frontend backend, React, Angular) converges he

This group is the HEART of the page: everything you learned in groups A-G (DOM, HTML, CSS, JS, frontend backend, React, Angular) converges here into ONE skill — being able to look at any element and pick the most durable locator. Across this group's 8 topics you will learn the durability hierarchy, antipatterns, thinking of 5 locators for the same element, conditional/dynamic elements, list rows, shadow DOM/iframes, what to ask the developer for, and locator code review.

🏆 H1. The Locator Durability Hierarchy

Choosing a locator is like describing a person: if you describe them as "the person third from the left, in a red shirt" (index + appearance), your description collapses when the order changes or the person changes clothes; but if you say "the person whose national ID number is X" (data-testid), that person is found wherever they sit and whatever they wear. The locator durability hierarchy is exactly this: `data-testid` > `role`+`name` > stable `id` > text > CSS > XPath-index (last resort). Why a hierarchy? Because each layer depends less on "coincidence" than the next — data-testid is a deliberate identity, while XPath-index is a fragile assumption about the DOM's current shape. Java analogy: it is the question of whether you equate an object by its identity (id) or by a transient field (color/order). In QA context: a tester who internalizes this hierarchy can think of 5 different locators for any element and justify the most durable one. Below is the **Locator Lab**: click the attributes on a DOM fragment and see which locator is more robust and why.

According to the Locator Lab's BugCard DOM, which ordering from most durable to most fragile is correct?

class > id > data-testid > text

data-testid > role/id > text > class

text > class > data-testid > id

All are equally reliable

data-testid is at the top (exists solely for tests, unaffected by anything), role/id is second, text can break under i18n, class (especially hashed) is most fragile because it exists for styling.

Why is "most durable" and "shortest to write" generally NOT the same locator?

They are always the same

A short spelling (e.g. `.btn`) usually binds to a shared, styling-purpose field; durability comes from binding to a DELIBERATE identity

Short locators are always slower

Long locators are always safer