In my experience, using unique identifiers is better since it allows for better readability and debugging. Sometimes, Playwrightâs built in locator picker will use some other methods like page.getByRole('button', { name: 'submit' }); which you cannot immediately locate in the inspect tab of a browser. With unique identifiers I have the chance to look at test failures which have self explanatory locator names like page.locator(FEEDPAGE_LOCATORS.createPostButton).click()
I want to know what others think?
Do you use unique identifiers too or have you experienced Playwrightâs built in methods to be better?
(P.S We canât do test-ids because of obvious reasons. Otherwise theyâre the best!)
When I have access to the product source code I add myself identifiers.
Might not be the best placement sometimes.
âTo make tests resilient, we recommend prioritizing user-facing attributes and explicit contracts such as page.getByRoleâ
Iâd think youâd want to avoid automating UI checks of things that arenât even on the screen for a user.
They are on the screenâŚbut as i mentioned in the example above, I have unique identifiers such as id attributes which I can use instead of the playwright page.getby methods.
What is stopping you in using them?
Choose whatever is appropriate for you.
Not all development teams have a product thatâs designed similarly.
As youâve excluded the first recommendation of using unique ids, and the second of prioritizing user-facing attributes & explicit contracts, then itâs down to the quality of the code your team is developing and youâre developing against.
You could use a mix depending on the stability, elements interactions, asynchronous events, delays, technical debt, accessibility built in, etcâŚ
Iâve had problems and success with both, the Playwright suggested locators and my own locators. I canât tell which is better. Itâs up to me as a developer to understand the design of what Iâm trying to build.
Agreed. I too resort to Playwrightâs built in methods when my unique identifiers donât help. Owing to my teamâs work dynamics, I canât really add identifiers on my own.
Background: Iâm doing small reviews of my code these days hence the query.
Thanks for the input though, helped clarify doubts.
Caveat; Iâve mostly discussed test automation with the devs that did it and have not myself âownedâ a large test suit, so I might not know what Iâm talking about.
Itâs an interesting question, and while I do think readability and debuggability etc. is valuable and important, it reminds me of the old saying âThe purpose of a test is not âto be easyâ, but âto be valuableââ.
The documentation you link to recommend testing things like the user will use it, and not rely on implementation. I guess this is because 1) The product is built to be used by the user, not the test automation engineer, and 2) It decouples the tests from the implementation, allowing it to be refactored without having to update the tests, which I think is generally considered a Good Thing.
The user is obviously not going to look in the inspector to find a field with the id #username. They will fill in their name in that input with the placeholder âEnter usernameâ.
And⌠they will click that button with the text âsubmitâ on it.
This makes sense to me, but I can see how it might be a bit jarring if youâre used to do it differently.
One last observation;
You say âOwing to my teamâs work dynamics, I canât really add identifiers on my own.â
This, to me, sounds like test automation is a siloed activity at your place, which makes my toes curl up (and not in a good way). Unless there are some really, really, good reason for it, I believe the pair whoâs working on a story should do all the things necessary to bring it to Done. This might include getting advice from, or collaborating with an expert if necessary.
It also sounds like a great reason to decouple from the implementation, like Playwright suggests.
Iâm the only tester here soâŚ
But
Adding to your points, the team i work with really donât communicate actively. Therefore, I take measures to ensure some robustness. A well followed process should allow for doing what Playwright guides.
Iâd see it differently, itâs you that own the test automation. I expect you to actively communicate with them and engage them and propose to them ways of dealing with automation.
As youâd need their input for you to build something that would help them.
And they need to see value in what you do and itâs output, otherwise itâs like working on a personal project.
I havenât interacted with web UI test tooling in long time, so I may be dated here. But from perspective of usage and coding across tools, if want something more adaptable across tooling and re-use of code, then I suppose the unique identification strategy (when by CSS, XPath, IDs, class name, attributes) may be more ideal in that it works across tools like Playwright, Selenium WebDriver, Appium, and even some desktop automation tools like WinAppDriver.
Tool specific features/strategies (not commonly available in other tools) are best used when there is a compelling reason to, or as a last resort. Also doesnât hurt to use if you plan to stick with the tool and have expertise in it.
That makes sense. Most sensible when things just work. (and ideally optimal performance in execution - time, CPU, memory, reliability/repeatbility).
But unless/until such (AI like?) functionality works well enough most of the time, might have to do things the old way as workarounds.
Following on this user centric approach, pre-Playwright days, I did use such a strategy with advanced XPath locators, defined in such a way based on user noticeable text to do the final locating against or descriptive element attributes that can map to tests by text (e.g. name of color you would test with, where said name is used in element attribute value). This way the locators are technical by definition but also user acceptance test readable in terms of intent when abstracted away in page object method actions, etc. Hopefully Playwright has done a good job abstracting all that away for the QA person to not need advance skills to pull off what I did before.
hence the query.