XPath, strict mode, and locators for elements that change

• What XPath is: a W3C query language over the document tree
• Absolute versus relative XPath, and why absolute is banned in the framework
• The core syntax, and what the star costs you
• Testing an expression in DevTools before it goes in code
• A confidence ranking for attributes: id, data-qa, name, placeholder, class
• Converting an XPath into a CSS selector by dropping two characters
• Playwright strict mode, and what first, last and nth actually admit
• Building the spec live, including the two failures on the way
• XPath functions: contains, starts-with, ends-with, text, normalize-space
• Handling dynamic elements whose ids change on every build
• XPath axes, and the one place they earn their keep: web tables

The structure of a Playwright test is covered, and page.goto() with its options was the last thing looked at. Before the class reaches the locators it will actually use day to day, it is doing XPath and CSS properly.

An HTML document is a tree. html contains head and body, the body contains divs, those divs contain more. XPath is a query language for selecting nodes in that tree, the way SQL selects rows, and it works on XML too.

It is a W3C standard, which is the fact that matters: anything defined at W3C is supported by every modern browser. The same is true of CSS selectors, which is why both work everywhere without a plugin.

The core shape:

//tagname[@attribute='value']
  |      |     |
  |      |     the attribute: id, class, name, alt, href, src, data-qa, anything
  |      the tag: input, a, div, h1, form, or * for any
  anywhere in the document

Absolute XPath is the full path from the root. It is what you get from Copy full XPath in DevTools:

/html/body/header/div/div/a

Relative XPath starts from any recognisable anchor and finds the element from there:

//a[@id='btn-make-appointment']

Try it in the browser before you put it in code. Open DevTools, press Ctrl+F in the Elements panel and paste the expression. It reports how many nodes matched. 1 of 1 means you have a unique locator. Anything else means you have work to do, or a decision to make.

The most useful idea in the session, and it applies just as much to CSS and to the default locators that come later.

Asked in class whether the @ is required, and the answer turned into the most practical thing in the session.

//input[@id='free-trial-step1-email']     XPath
  input[id='free-trial-step1-email']      drop // and @, and it is CSS
       #free-trial-step1-email            CSS knows the tag from the id

Both forms go into Playwright the same way. The explicit engine prefix still works and is the older style:

page.locator("xpath=//input[@id='free-trial-step1-email']")
page.locator("css=#free-trial-step1-email")

But you do not need it. Pass the selector directly and Playwright works out which it is, because any string starting with // is treated as XPath:

page.locator("//input[@id='free-trial-step1-email']")   // XPath
page.locator("#free-trial-step1-email")                 // CSS

Playwright runs every locator in strict mode. If a locator matches more than one element, the action throws rather than silently picking one.

This is a deliberate design choice and a good one: silently acting on "the first thing that matched" is how a suite ends up clicking the wrong button for six months with nobody noticing.

When a locator legitimately matches several elements, three escape hatches:

page.locator("//div[contains(@class,'invalid-reason')]").first()
page.locator("//div[contains(@class,'invalid-reason')]").last()
page.locator("//div[contains(@class,'invalid-reason')]").nth(11)   // the 12th

The scenario: on the Wingify free trial page, enter an invalid email, submit, and verify the error message.

The locators chosen, and why each one:

import { test, expect } from '@playwright/test';

test("Verify the error message in the wingify free trial", async ({ page }) => {
    await page.goto("https://wingify.com/free-trial/");

    await page.locator("//input[@id='free-trial-step1-email']").fill("abccd");
    await page.locator("[data-qa='free-trial-step1-gdpr-consent-checkboxgdpr-consent-checkbox']").click();

    const errorMessage = page.locator("//div[contains(@class,'invalid-reason')]").first();
    await page.locator("//button[@data-qa='page-su-submit']").first().click();

    await expect(errorMessage).toContainText("The email address you entered is incorrect.");
});

It failed twice on the way, and both failures teach something.

1. The error element is a div, not an input. Writing //input[contains(@class,'invalid-reason')] matched nothing. Check the tag in the inspector before you write the expression.
2. The error never appeared, because filling the field is not enough. The submit button has to be clicked for validation to run. A missing step, not a missing locator, which is the more common cause of "my locator does not work".

The one improvement the repository makes on the live code

Worth flagging rather than quietly fixing, because the difference is a real source of flake.

As typed in class, the assertion read the text first and then checked the string:

const text = await errorMessage.textContent();      // samples the DOM once, right now
expect(text).toContain("The email address you entered is incorrect.");

That assertion does not retry. It looks at the page at the instant it runs, so if the error renders 50 milliseconds later, the test fails on null. The web-first form polls until it matches or times out:

await expect(errorMessage).toContainText("The email address you entered is incorrect.");

Relative XPath assumes the attribute value is fixed. Often it is not.

Dynamic elements are the reason these functions exist. A generated id like puis-a1b2c3-title changes on every build, and a date-based id changes tomorrow. Find the part that does not change and anchor on that:

//div[contains(@id,'cell-widget')]        the stable middle
//span[starts-with(@id,'puis-')]          the stable prefix

Shown live on a search results page, where the product title ids are generated but share a fixed prefix, and contains() returned the whole list of titles.

The last XPath concept, and the class was upfront that it has essentially one application.

If you can find one element, axes let you walk to its relatives:

//div[@class='mammal']/following-sibling::div
//div[@class='mammal']/ancestor::div

• Homework: automate the student login on the batch's multiple-element practice page. Fill in an email and a password, click the login practice button, and verify that the URL changes. One test case is enough.
• A doubt thread is being created; post questions there rather than in chat.
• Finish the certification and post it on LinkedIn.
• Register for the BrowserStack summit using an official work email.
• Next class: XPath axes applied to web tables, then CSS selector mastery. The axes section above is the preview of it.