-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] codegen: choose between multiple generated selectors #5178
Comments
The main goal of the The QA world is split on the self-healing topic (some prefer to assert behavior, others to keep test running in a best effort manner). We don't have an opinion on this matter, we consider this to be a higher-up-the-stack decision. |
Maybe another cool approach for this would be: https://playwright.dev/docs/selectors#selecting-elements-based-on-layout |
In v1.10, generated selectors overall work pretty good. If there are any specific instances where the selector is really bad, please file a separate issue with repro steps. I am renaming this issue to be about generating multiple selectors and choosing one of them (as suggested in the original request). |
As a user would like an option to explicitly define or influence what properties the recorder looks for and uses for the selectors in the generated code emitted by the recorder. Personally, not a big fan of tools second guessing and assuming they know what is best, would assert there are "data-XXX" defined in the HTML spec that could be used for this purpose. Would assert it would actually make it easier and more often since we as users know and understand our specific code bases, might make it easier for all involved. Cases where the selector fails because multiple items match... Fine easy to understand and fix up my code as needed and handle thos cases needed, but at least we get what we needed. |
What I am doing now is to add an eventlistener to elements with the attribute I want to record, for example:
and then console.log the actual selector that I want. I can imagine that something like this would be helpful:
|
Hello, just wanting to bring attention to this thread again because it is also something my team would like implemented. The selectors codegen generates are not always the ideal selectors for our codebase. For example, they use class names or aria labels that change more frequently rather than more stable elements such as data-unique-id. Having the option to choose would greatly improve the usefulness of codegen. Any updates on if this feature will get development? |
I think to be fair, when entering my comment before, it seemed the recorder wouldn't pick up the data-test-id, running with 1.21 i'm seeing if data-test-id is present it is using it. Was hard to justify asking the devs to go to the trouble of putting the id's in the product code but they would be used... From my simple test, it appears data-test-id will be used. |
Based on id, data-testid, data-test-id, data-test selectors and a short test it seems that This markup <label>Name<input type="text" data-test="trader_search_by_name" data-val="true"
data-val-required="The Name field is required."
id="Name" name="Name" >
</label> resulted in await page.locator('[data-test="trader_search_by_name"]').fill('Foo'); |
Is this behavior something we can count on @dgozman @pavelfeldman? We have been interested in providing codegen a hint to use a data attribute as well. This would save immense time. |
@Jojoshua Yes, codegen always checks and suggests test ids. |
Would love to see this feature implemented (see my issue linked by dgozman above for another way it could be implemented) |
Even just being able to exclude id from the codegen would be a big help (our app uses dynamic id's throughout). |
Yes please. That would be quite useful! |
I would also find it very useful to be able to define an order of precedence for attributes to use as selectors through codegen. |
Another idea: Add a configuration option that adds all the alternative selectors as commented-out code in the generated code. |
+1 on adding an option to prefer user-facing locators.
|
@dgozman : Thanks to a colleague,
How does multiple: true ever get passed in? I tried upgrading playwright to 1.44 and still can't use this feature. Also, I tried downloading the source code and I tried to hardcode the value
Then |
@esther-86 This feature was disabled, as it was deemed not yet ready. Sorry for confusion. Let me reopen the issue. |
ah... sad to see it go for now, i had been using it in a forked repo as well. what was not ready about the feature? (as it was really usefull to the team) |
it would be great if the inspecting element suggests "react", "vue" selectors as well |
In some cases the generated selector isn't stable enough for rerunning the code.
Having multiple selectors per element could solve this, similar to how testim.io does this - https://help.testim.io/docs/working-with-locators#:~:text=Testim%20Smart%20Locators%20are%20a,application%20to%20write%20the%20tests.
The text was updated successfully, but these errors were encountered: