An end-to-end suite locates elements by their visible text, such as a button reading "Add to cart". The product then ships in five locales and the copy team rewords labels regularly. What breaks, and how do you keep the tests readable without coupling every test to product copy?

## Why text feels right and behaves badly Matching on "Add to cart" reads beautifully in a spec: it is exactly what a user looks for, and a failure message quoting it is instantly understandable. That is why text-based and accessible-name locators are recommended. The catch is that the string is **product copy** — owned by writers, translated by a pipeline, and changed for reasons that have nothing to do with behaviour. The ways it moves are worth enumerating, because candidates usually name only translation: - **Localisation.** A German build changes every label simultaneously; one locale switch reds the whole suite. - **Copy edits.** "Add to cart" → "Add to basket" → "Add". Behaviour identical. - **Interpolation and pluralisation.** "Cancel 1 order" versus "Cancel 2 orders": an exact match fails on data you did not control. - **Whitespace and invisible characters.** Text split across elements, non-breaking spaces, or a trailing icon can defeat an exact match even when the rendering looks identical. Most locator APIs normalise whitespace for you, which helps but does not cover casing or punctuation. - **Truncation.** CSS ellipsis does not change the DOM text, but a component that truncates in JavaScript does. This is not an argument for going back to CSS paths. Text remains far more meaningful than a class name. It is an argument for **deciding where copy is allowed to be an input to your tests**. ## Pin the locale The simplest, highest-value move: the suite runs against one known locale, chosen explicitly rather than inherited from whatever machine executes it. That usually means forcing the app's language — through the app's own locale mechanism, a seeded user preference, or the browser context's language configuration your tool exposes — instead of letting a CI runner's system locale decide. Now the strings are deterministic, and the multi-language question becomes a *separate*, small suite rather than a tax on every test. That separate suite is worth having and should be deliberately tiny: a handful of smoke journeys per locale that check the app renders and functions in that language, plus checks for untranslated keys leaking through. Running the entire regression suite once per locale multiplies runtime for very little extra signal. ## Resolve labels from the catalogue Where a test must reference a label that genuinely changes, import the same translation resource the app uses and look up the key: ```js import messages from '../../src/locales/en.json'; await page.getByRole('button', { name: messages['cart.add'] }).click(); ``` Now a writer's edit updates both sides in one commit. The cost is a coupling to the catalogue's shape and a spec that reads slightly less like English; the benefit is that copy churn stops being a source of red builds. Use it for labels that move often, not everywhere — a hard-coded string is more readable, and for stable labels that readability wins. ## Separate "copy is the subject" from "copy is the route" This is the distinction that answers the question. Some assertions are *about* wording: an empty-state message, an error message, a legal disclaimer, the confirmation text after checkout. Those should be matched on text and *should* fail when the copy changes — that is the test doing its job, and a writer updating the string updates the test with it. Most text matches, though, are just navigation: click "Add to cart", click "Continue", click "Pay" — the assertion at the end is about the order being created. For those, the label is incidental, and coupling hundreds of tests to it is what turns a copy edit into an afternoon. Where such a step sits on a high-traffic path and its label churns, an owned test id on that control is the cheaper contract. ## Matching mode matters Exact matching is precise and brittle to punctuation; substring matching tolerates a trailing icon or period but can match more elements than you meant — "Cancel" also matches "Cancel all". Choose per case, and remember that whichever you choose, matching text never identifies an *instance* on a page with repeated rows; you still scope to a container first. ## The summary an interviewer wants Text selectors are excellent identity and poor stability. Make the strings deterministic by pinning locale, derive them from the source of truth when they churn, and be explicit about the small set of tests that are supposed to break when the words change — because those are the ones actually protecting the copy.