Our app renders a summary table where the only stable thing about a row is its position relative to a header cell. The reviewer agent keeps flagging the selector, so I was going to declare a fallback for it:
readonly total = this.heal.locator(this.page.locator('.summary .total'), {
description: 'order total',
css: ['xpath=//table[@id="summary"]//tr[last()]/td[2]'],
});Does the healer accept that? And if it does, is it a terrible idea?
Accepted answer
It will not throw at you, because the strings in css go straight to page.locator() and Playwright resolves an xpath= prefix. It will also never once be used.
Candidates built from css carry a base score of 0.4. The score is base × uniqueness × visibility × enabled + history, and the history bonus is capped at 0.1, so the best a CSS or XPath candidate can ever reach is 0.5. The default minScore is 0.6. That is arithmetic, not policy — the candidate loses every time, on every page, forever.
The order that does work is role and accessible name, then label, then the project test id, then placeholder, then text, and CSS only as a last resort inside a page object that has a real context around it. XPath is not on the list at all: it encodes document structure, which is the one thing a refactor is guaranteed to change.
For your table, give the row an accessible name or a test id in the application. That is a ten-minute change in the app and it removes the problem instead of describing it.
If you genuinely cannot touch the app, scope the locator instead of positioning it — find the row by its content and read the cell inside it:
readonly total = this.heal.locator(
this.page.getByRole('row', { name: 'Order total' }).getByRole('cell').nth(1),
{ description: 'order total' },
);Still not lovely, but it survives a column being added above it, which tr[last()]/td[2] does not.
Have the same question?
Ask it with the command you ran and the output you got, and it will be answered here.
Ask a question