Recorded spec is all .btn_primary and nth-child — fix the locators before or after converting?

Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.

Recorded a checkout. The spec is mostly this:

await page.locator('.inventory_item:nth-child(3) > .pricebar > .btn_primary').click();
await page.locator('#checkout').click();

Each of those came back with a // sdods:fragile comment above it, and the CLI finished with

text

⚠ 12 CSS/XPath locator(s) marked // sdods:fragile — prefer role/label/test-id locators.

I would rather not convert this into a feature and inherit twelve selectors that break next sprint. What is the right order of operations?

recording locators page-objects

asked by Nikhil Sane

3 answers

Accepted answer
Fix them in the spec, then convert. Conversion reads the spec you hand it — whatever locators are in there end up in the page object the generator proposes, fragile comments and all. There is no pass in between that cleans them up for you.
Before you touch anything by hand, check testIdAttribute in sdods.project.yaml. Codegen is started with --test-id-attribute taken from it, so if your app has test ids and the project does not name the attribute, codegen has no idea they are ids and falls back to CSS. demo-shop sets
yaml
```
testIdAttribute: data-test
```
which is the only reason its recordings come out with getByTestId and yours do not.
Then re-record instead of editing forty lines. The fragile marker is a line heuristic — anything starting #, ., [, //, xpath= or css= — so once the locators are role or test-id based the count in that warning drops to zero and you know you are finished without reading the diff.
answered by Thom Vasseur
The priority, in order: role plus accessible name, then label, then the project's test id, then placeholder, then text, then CSS. XPath never.
Where a CSS locator is genuinely the only handle the markup gives you, do not leave it bare. Put it in a page object and give the healer somewhere to go:
ts
```
readonly title = this.heal.locator(this.page.locator('.title'), {
  text: 'Products',
  description: 'page title',
});
```
The primary stays the one you believe in; alternatives are only probed when it fails, and you are told which one won. A recorded .btn_primary with no context is a locator with no fallback, and that is the real problem — not the CSS itself.
Self-healing locators covers what goes in the context object.
answered by Tomas BrekkeSDODS team
Cheap trick that worked on our frontend team: record the flow twice, once against the app as it is and once against a branch with data-test attributes on the four components you care about, and put the two specs side by side. It is a much shorter conversation than a paragraph about locator stability.
answered by Bea Lindqvist

Know the answer?

Wrap commands and output in triple backticks and they will render as a code block.

Checking whether you’re signed in…

Have a different question? Ask it.

Recorded spec is all .btn_primary and nth-child — fix the locators before or after converting?

3 answers

Know the answer?

Related