microsoft / playwright-java

Java version of the Playwright testing and automation library
https://playwright.dev/java/
Apache License 2.0
1.15k stars 207 forks source link

[Feature] Possibility to configure parameter for code creation through recording #1227

Open morepe opened 1 year ago

morepe commented 1 year ago

With playwright version 1.27.0 the code that is created through recording has changed completely. See below the same flow recorded with a recent version and with 1.26.0: grafik

Previously we consistently got "page.locator" entries, now we get a mixture of "page.getBy"... and "page.locator" entries. Additionally we get some entries that are very difficult to read:

difficult_to_read

So in the current version the recording is not usable to us, as it would create inconsistent selectors. What we are prefering in our project are selectors identify by text and chain back/forward to other text like this:

wanted_selector

As every project has different preferences I suggest of introduce a configuration possibilities on created code where you could specfiy things like: "always use the attribute id unless there is a text on the element".

Some ideas for configuration possibilities:

mcturtle987 commented 1 year ago

Some commercial tools (that I will not name here :) ) are using something called "path weights" to achieve that. It would be nice to have that. Our application uses a custom attribute that the developers put on elements, we would really like to use that, but Playwright does not give us the option to configure the recorder to prefer that attribute if it is present. Therefore, we are not using the recorder. Please expose something like "path weights" or similar.

yury-s commented 1 year ago

Previously we consistently got "page.locator" entries, now we get a mixture of "page.getBy"... and "page.locator" entries.

It was a deliberate decision in 1.27 to make the codegen prefer new locator APIs introduced in that release . You can watch the video linked in those release notes to learn more about the rationale behind that.

Additionally we get some entries that are very difficult to read:

If you have a concrete example how to automatically generate a better selector, we can probably incorporate the logic into the codegen algorithm. Note that the codegen doesn't have any knowledge about the app specifics. This code gives an idea of current prioritization of different types of locators (you can see in particular that css selectors are at the bottom of the list). You can always edit generated code to better fit your app and environment.

morepe commented 1 year ago

Thanks for the video. I always only check the Java release notes as we are using the Java Version. Could you maybe also link the videos there? That would be helpful.

This code gives an idea of current prioritization of different types of locators (you can see in particular that css selectors are at the bottom of the list)

Would it be possible, to make the variables that you are already using for the calculation of the selector, chonfigurable from outside? That would already pretty much cover this feature request