Selenium Page Objects have Individual Method for Every DataQa?

Question

Our QA Automation Test project uses Selenium with data-qa attributes. Our company is proposing having Individual Methods for each By attribute: eg for SendKeys, Clear()

I believe this may lead to duplicate coding, and can triple the code base.

Option 1:

SendKeys Method for each Attribute

private By StreetNameTextbox => By.XPath("//*[@data-qa='streetname']");
private By CityTextbox => By.XPath("//*[@data-qa='city']");
private By StateTextbox => By.XPath("//*[@data-qa='state']");
private By ZipCodeTextbox => By.XPath("//*[@data-qa='zipcode']")

public void SendKeysStreetNameTextbox(string value) => SendKeys(StreetNameTextbox, value);
public void SendKeysCityTextbox(string value) => SendKeys(CityTextbox, value);
public void SendKeysStateTextbox(string value) => SendKeys(StateTextbox, value);
public void SendKeysZipCodeTextbox(string value) => SendKeys(ZipCodeTextbox, value);

public void ClearStreetNameTextbox(string value) => FindElement(StreetNameTextbox).clear()
public void ClearCityTextbox(string value) => FindElement(CityTextbox).clear()
....

Option 2:

Don't need individual SendKeys and clear, just use native Selenium Send Keys or company wrapper function, why have repetition? Test user can just input appropriate data-qa tag id.

private By StreetNameTextbox => By.XPath("//*[@data-qa='streetname']");
private By CityTextbox => By.XPath("//*[@data-qa='city']");
private By StateTextbox => By.XPath("//*[@data-qa='state']");
private By ZipCodeTextbox => By.XPath("//*[@data-qa='zipcode']")

SendKeys(variablename, value);
clear()

The question is, do we really need repetition in Option 1? Company is saying, Page Objects should not really work with By DataTags as little as possible. Is this true? What is best practice?

Answer 1

This is from selenium : https://www.selenium.dev/documentation/en/guidelines_and_recommendations/page_object_models/

There is a lot of flexibility in how the page objects may be designed, but there are a few basic rules for getting the desired maintainability of your test code.

Page objects themselves should never make verifications or assertions. This is part of your test and should always be within the test’s code, never in an page object. The page object will contain the representation of the page, and the services the page provides via methods but no code related to what is being tested should be within the page object.

There is one, single, verification which can, and should, be within the page object and that is to verify that the page, and possibly critical elements on the page, were loaded correctly. This verification should be done while instantiating the page object. In the examples above, both the SignInPage and HomePage constructors check that the expected page is available and ready for requests from the test.

A page object does not necessarily need to represent all the parts of a page itself. The same principles used for page objects can be used to create “Page Component Objects” that represent discrete chunks of the page and can be included in page objects. These component objects can provide references the elements inside those discrete chunks, and methods to leverage the functionality provided by them. You can even nest component objects inside other component objects for more complex pages. If a page in the AUT has multiple components, or common components used throughout the site (e.g. a navigation bar), then it may improve maintainability and reduce code duplication.

There are other design patterns that also may be used in testing. Some use a Page Factory for instantiating their page objects. Discussing all of these is beyond the scope of this user guide. Here, we merely want to introduce the concepts to make the reader aware of some of the things that can be done. As was mentioned earlier, many have blogged on this topic and we encourage the reader to search for blogs on these topics.

So as you can see Page object model is just a design pattern recommendation that helps to reduce the complexities in test maintenance. There is no strict coding standards or recommendations than these few that is suggested above.

Benefit of Option 1:

1. Faster reusability of code due to auto-complete feature in IDE, eg you call page1. and it will suggest all the available methods inside that page
2. If any textbox has additional logic requirement like sending keys one by one then the code looks cleaner as it's in its own method

Demerits of Option 1

1. Too many unnecessary lines of code
2. No code reusability in this design
3. Hard to maintain in long run when the page has too many elements and actions

Benefit of Option 2:

1. Cleaner code
2. Fewer lines of code
3. More code reusability
4. Can handle special cases with if or switch cases

Demerits of Option 2:

1. IDE autocomplete won't be much helpful. Developer should check variable name from the class each time he/she wants to use it
2. If different elements require different logics to make it work, then can end up with too many loops in a single function and can look awful