TestProject Forum
Powered by leading experts in the test automation community

Wrapping Element Access with a self defined Addon

I’m thinking about the idea to put all our element locators into one or more Java Classes, coming close to POs, pack them into a addon and use it instead of the elements here in TP.

The reason is that we do have a lot of them, now maintained in a file and they are changing a lot. The maintenance of TP elements consume too much effort and the idea to dump and load them as text files is not yet realized.

Now my question is: does anyone use a similar approach and what are the pitfalls?

Regards

Hello,
That does indeed seem like a plausible idea, you can create an addon that will act as storage for everything you need during your tests and use an action that retrieves values from your storage as needed.

The only pitfall I can see from this approach is the need to maintain that addon and constantly update, rebuild and re-upload it when wanting to add or update values for your tests.

There is also an option to use data driven tests, you can create parameters in your tests and update the CSV file’s values to be the elements you need and use those during your tests as well.

Can you please explain what you do not like about element management in TestProject? We are always open to suggestions and new ideas.

Hi David,
thanks for your fast response. I made the proposal, that there might be an option to down- and upload element definitions and tests/testsequences as text/json files and the idea was taken up I think.

Until it is realized we are looking for a solution that comes close to it. Especially the maintenance of the element definitions is a little cumbersome, so we will hold all of our element definitions in a file (or two …) that is connected with this addon. If there are changes to the element path then we will maintain it in the file, generate a new version of the addon.

That is much easier for us for several reasons:

  • we have the element path under control of git
  • it is much faster to do a search and replace than going through the element definitions in a gui
  • we do not need an accout for, e.g. given every developer, that has to give us the definition of a new selector

You mention it is possible to store element definition in a CSV file yet? I always thought data driven is only about values you use not the CSSselectors or stuff like this.

Regards

As long as you create parameters and use them as the element locators, you will be able to update them through the CSV file, in this example I created a parameter that will be used as my XPATH element locator:
image

and set the value through the CSV file:
2

This looks very interesting! Application and MyXPath are obviously column headings.
This means we have one CSV per Selector or do I get it wrong?

If this is possible we happily will use it I think:

Application;LocatorName;LocatorValue
…;LocLoginUser;CSS-Selector here
…;LocLoginPassword;CSS-Selector here

Regards

The format is like this:

Application;Locator1Name;Locator2Name;Locator3Name; - These are the column names and params
Application1;Locator1Value;Locator2Value;Locator3Value; - First execution with these values
Application2;Locator1Value;Locator2Value;Locator3Value; - Second execution with these values

The test will be executed once for each data row in the CSV file.

We will try this, thanks a lot