Implement custom locator option for the use of test IDs.

[se2021]

@danhumphrey First of all. Thanks for your terrific open source software. After comparing a bunch of browser extensions of the same category I always came back to the Page Modeller extension. But one feature was missing in my special case so I implemented it. See below for more details.

Situation

Some web development teams decorate the elements in their web pages with unique ids. These test ids are used by the tester as stable locators for automated tests. The test ids are custom attributes with each a unique value for its scope.

Examples:

data-qa="loginpage-loginbutton" 
data-qa="loginbutton-X23x45AcD"
data-qa="4cd9d37a-462a-4971-8046-0f0a8d12a15d"

The Page Modeller should support the scanning for such custom locators.

Solved by this Branch

This branch adds support for such test ids to the Page Modeller. In the Page Modeller configuration there are two new options available for this purpose.

1. Configuration option for the attribute name of the custom locator.
2. Optional: Generate the name from the value of the configured attribute.

Comparison of Page Modeller behaviour

Custom Locator Configured	Name from Attribute Value	Result: Name	Result: Locator
-	False	Login	linkText: Login
data-qa	False	Login	customLocator: [data-qa="login_button"]
data-qa	True	LoginButton	customLocator: [data-qa="login_button"]

Like demonstrated in the example above the custom locator is a CSS locator. Thus all templates supporting CSS are able to use the custom locator. In this branch all templates are adapted to the custom locator.

Note: Import appOptions

It is just my second short foray into the Javascript world. So you should have a special look on my access to the appOptions. To prevent cyclic imports I have avoided to import the appOptions into the dom.js directly. Instead I used the existing appOptions imports and proliferated them as parameter when calling functions.

[se2021]

Deleted the Python template file. This file was accidentally added to the commit.

[danhumphrey]

Hi @se2021, Thanks for your interest.

Why wouldn't you just use a CSS selector such as

[data-qa$="loginbutton"] (ends with loginbutton) [data-qa^="loginbutton"] (starts with loginbutton) [data-qa*="loginbutton"] (contains loginbutton)

Thanks, Dan

[se2021]

Hi @se2021, Thanks for your interest.

Why wouldn't you just use a CSS selector such as

[data-qa$="loginbutton"] (ends with loginbutton) [data-qa^="loginbutton"] (starts with loginbutton) [data-qa*="loginbutton"] (contains loginbutton)

Thanks, Dan

Hi Dan. The web developer must ensure that the data-qa value is unique on a single web page. So this in my mind results into a strict selector. Maybe your suggestion could be another toggle to loosen the strictness and add a litte bit of fuzziness when needed. In this case I would suggest the contains variant. It can be applied more generally than the other two.
Regards

[danhumphrey]

I still don't understand what problem you are trying to solve that can't be achieved with the existing functionality.... you can already add any element you wish to a model and use css or xpath to identify it using the data-qa attribute (for instance).

After scanning, you can also use the edit functionality to name or rename any element in the model and overwrite or amend any of the automatically generated locators before exporting code.

Do you have an example HTML fragment and use case that can't be achieved without your pull request?

[se2021]

Maybe I overlooked some functionality. To be sure that we are talking about the same. Is this the workflow you mean with "you can already add any element you wish to a model and use css or xpath"?

a. Press button "Add Element" in Page Modeller view b. Select Element in browser by clicking c. Go back to Page Modeller view and edit element d. Adapt the locator setting

And this I have to do for every element? Am I right?

In this case: yes, it can be achieved without my pull request. But only by additional editing work which could be avoided in my specific circumstances .

If all assumptions above are correct then it is a discussion about the feature scope of your plugin. And we are talking about an edge case for your plugin from your point of view. Only for specific users applicable and not the general users. And that you want to keep the functionality of the plugin clean and not being cluttered with specific features. Certainly you would have to maintain additional code and you would do it in your spare time. I can get along with it and I understand it.

You can close this merge request. Thanks again for your time and the useful plugin. :)

[danhumphrey]

Yes, you can (and most probably should) review and edit the generated locators - automatically generated models are helpful to assist the engineer and speed up the workflow, not perform all of the work - my code makes a good educated guess at useful elements and their appropriate locator strategies.

The typical flow would be to scan an area of a page to generate a model, then add any additional elements that weren't automatically added, review the names and auto generated locators (editing any that could be improved), then export the code.

Yes, your requirement is an edge case that wouldn't apply to many other users so I would prefer to keep the functionality generic.

Thanks again for your interest in the project!