Multiple elements, the three text getters, and web tables with dynamic XPath

• Recap: session state in the default config, the Allure report and the custom reporter
• One locator for many elements, and reading all their text with allInnerTexts()
• Why getByText matched six elements, and what first() and nth() do about it
• all(): an array of locators, for when you need to act on each element
• all() versus allInnerTexts() versus allTextContents(), and innerText versus textContent
• page.pause() and --debug for stepping through a spec
• A reusable spec template, a /start-pw command, and a warning about leaning on AI
• How a web table is built: table, thead, tbody, tr, th, td
• The interview question: find Helen Bennett's country with a dynamic XPath
• A second table read with CSS locators, and an off-by-one in its loop

The class opened with a recap of the previous session: a saved session state can be set in the default Playwright config so every test starts logged in, with the usual warnings (states expire, never commit them, regenerate the token, keep the test user stable). The Allure report and the custom reporter added last time were both confirmed working.

The rest of the week covers handling every kind of element: multiple elements, input boxes, web tables, iframes and frames, windows, shadow DOM, file upload and download, scrolling, expectations, hooks and data-driven tests. Two changes were announced with it: every session this week is mandatory, and you can now write code straight into VS Code instead of drafting it in a notebook first, because the JavaScript and TypeScript groundwork is done.

The practice page has a right-hand panel of links, all sharing the class list-group-item. One CSS locator reaches all of them.

page.locator() itself is synchronous: it returns a Locator and touches nothing. allInnerTexts() is the call that goes to the browser, so it returns a promise and needs await. What comes back is a plain string[], one entry per matched element.

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

test('Basic verify how to handle multiple elements ', async ({ page }) => {

    await page.goto("https://app.thetestingacademy.com/playwright/multiple_element_filter");
    const rightPanelLinksTexts: string[] =  await page.locator('a.list-group-item').allInnerTexts();
    console.log(rightPanelLinksTexts.length);

    for (const link of rightPanelLinksTexts) {
        console.log(link);
    }

    for(const linkText of rightPanelLinksTexts){
        if( linkText === "Forgotten Password"){
             await page.getByText(linkText).first().click();
        }
    }

    const rightPanelLinks = await page.locator('a.list-group-item').all();
    for (const link of rightPanelLinks) {
        console.log(await link.getAttribute("href"));
    }

    await page.pause();

});

13
Login
Register
Forgotten Password
My Account
Address Book
Wish List
Order History
Downloads
Recurring Payments
Reward Points
Returns
Transactions
Newsletter
#login
#register
#forgotten-password
#my-account
#address-book
#wish-list
#order-history
#downloads
#recurring-payments
#reward-points
#returns
#transactions
#newsletter

The count is .length because the result is an ordinary array by then. A learner asked why not count(): count() is a method on a Locator, .length is the property of the array that allInnerTexts() handed back.

The first version of the click did not have .first(), and it failed. getByText('Forgotten Password') matches six elements on that page: the link in the panel, plus the same words in a heading, a code block, a span, and hidden copies further down. Playwright locators are strict, so an action on a locator that matches more than one element throws instead of guessing.

.first() resolves it by taking the first match. .nth(i) takes any other one, counting from zero. This is also why getByText is called brittle: the moment the same words appear anywhere else on the page, it stops pointing at one thing.

When you need to do something to each element, strings are no use: you cannot click a string or read its attributes. all() returns the matched elements as an array of Locator objects. It returns a promise that resolves to that array, so you await it once; after that, each item is a normal locator. getAttribute() is another trip to the browser, so it needs its own await.

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

test('Basic verify how to handle multiple elements ', async ({ page }) => {

    await page.goto("https://app.thetestingacademy.com/playwright/multiple_element_filter");
    const rightPanelLinksTexts: Locator[] =  await page.locator('a.list-group-item').all();
    console.log(rightPanelLinksTexts.length);

    for (const link of rightPanelLinksTexts) {
        console.log(await link.getAttribute('href'));
    }


    await page.pause();

});

This prints 13 followed by the same thirteen hrefs as above. The variable name says "texts" but the type annotation says Locator[], and the type is the one that is right.

The comparison table the class built:

The difference is the one between the DOM's own innerText and textContent. innerText is the rendered text, what is visible on screen. textContent is the raw text in the markup, including anything hidden. Use allInnerTexts() when you care about what a user sees, allTextContents() when you need the source text exactly.

On the thirteen links above, both getters return identical arrays, because the markup is clean. The difference shows up on the second web table later in this page, where each row ends in a cell holding nothing but a <br>. Same row, both getters:

allInnerTexts  : ["UAE","Dubai","829m","2010","1","\n"]
allTextContents: ["UAE","Dubai","829m","2010","1",""]

innerText turns the <br> into a newline; textContent has no text there at all.

page.pause() stops the run and opens the Playwright Inspector, so you can step through the spec and try locators against the live page. Running with --debug does the same from the command line. How you debug a Playwright test is a common interview question, and these two are the answer.

Every spec starts with the same few lines, so the class saved them as a template in the repo:

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

test('Verify the TestCase', async ({ page }) => {
   await page.goto("https://app.thetestingacademy.com/playwright/multiple_element_filter");

    // Code

   await page.pause();
});

Then GitHub Copilot was asked to turn it into a /start-pw command that drops the template into a new spec with a title. The command itself lives in the editor, not the repo, but the template file is in template/template.spec.ts. Remove page.pause() before you commit, because it halts the run.

A web table is an HTML table. Inside it: thead for the header rows, tbody for the data, sometimes tfoot for a footer. Every row is a tr. Inside a row, td is a data cell and th is a header cell.

The rule for any web table: count the rows and columns first. Every loop you write afterwards depends on those two numbers.

The class framed this as an interview question from Zeta, and said it has also come up at BrowserStack and iDrive. A table of customers has three columns: company, contact and country. Find Helen Bennett and report which country she is in.

Inspecting the table shows it has an id, customers, which helps. The header row sits inside tbody here, so tbody/tr counts seven rows including the header. Helen Bennett is in row 5, column 2, so the hard-coded XPath is //table[@id='customers']/tbody/tr[5]/td[2].

Hard-coding that is useless, because the data can move. The trick is to split the XPath around the two numbers and inject them from loops:

Once a cell's text matches, the country is the cell to its right. following-sibling walks right from a matched element; preceding-sibling walks left.

The spec, from after the page.goto line (the full file is 238_TestCase.spec.ts in the batch repo):

    const firstPart = "//table[@id='customers']/tbody/tr[";
    const secondPart = "]/td[";
    const thirdPart = "]";

    const rows = await page.locator("//table[@id='customers']/tbody/tr").count();
    const cols = await page.locator("//table[@id='customers']/tbody/tr[2]/td").count();

   for (let i = 2; i <= rows; i++) {

      for (let j = 1; j <= cols; j++) {

         const dynamicPath = `${firstPart}${i}${secondPart}${j}${thirdPart}`;
         // console.log(dynamicPath);
         const data = await page.locator(dynamicPath).innerText();
         // console.log(data);

          if (data.includes('Helen Bennett')) {
             const countryPath = `${dynamicPath}/following-sibling::td`; 
             const countryText = await page.locator(countryPath).innerText();
             console.log('------');
             console.log(`Helen Bennett is In - ${countryText}`);
          }

      }
   }

------
Helen Bennett is In - UK

Three details that the class stopped on:

• count() is a promise, so both counts need await.
• The column count comes from row 2, not row 1, because row 1 is the header and holds th cells, not td.
• XPath is 1-based. There is no row 0, which is why i starts at 2 and ends at <= rows.

The recap the class ended on: divide the XPath, count the rows and columns, loop, and step sideways with a sibling axis once you have a match.

const country = await page.locator('#customers tbody tr')
    .filter({ hasText: 'Helen Bennett' })
    .locator('td')
    .last()
    .innerText();

The second example reads every row of the sample table from the anatomy figure. Here the class converted the XPath to a CSS selector (//table/tbody/tr and table tbody tr describe the same thing) and read each row in one call with allInnerTexts().

The spec, from after the page.goto line (full file: 237_TestCase.spec.ts):

   const rows = page.locator('table[summary="Sample Table"] tbody tr');
   const rowCount = await rows.count();

   for(let i=0;i<rowCount-1;i++){
      // const colsheader = await rows.nth(1).locator('th').allInnerTexts();
      const rowsData = await rows.nth(i).locator('td').allInnerTexts();
      console.log(`Row ${i + 1}:`, rowsData);

   }

Row 1: [ 'UAE', 'Dubai', '829m', '2010', '1', '\n' ]
Row 2: [ 'Saudi Arabia', 'Mecca', '601m', '2012', '2', '\n' ]
Row 3: [ 'Taiwan', 'Taipei', '509m', '2004', '3', '\n' ]

Two things in that output are explained by the anatomy figure. The building names are missing because they are th cells and the locator asks for td. And every row ends in '\n' because the last cell holds only a <br>.

With i < rowCount, all four rows print:

Row 1: [ 'UAE', 'Dubai', '829m', '2010', '1', '\n' ]
Row 2: [ 'Saudi Arabia', 'Mecca', '601m', '2012', '2', '\n' ]
Row 3: [ 'Taiwan', 'Taipei', '509m', '2004', '3', '\n' ]
Row 4: [ 'China', 'Shanghai', '492m', '2008', '4', '\n' ]

Note the contrast with the first table: there, XPath positions run from 1 and the loop is i <= rows. Here, nth() runs from 0 and the loop is i < rowCount. Mixing the two conventions is exactly how this slip happens.

• Practise both web table examples until you can write them without looking.
• Next class: pagination and filtering on web tables, where the real difficulty is.
• Doubt thread is open for questions from this session.
• No masterclass this week.