Is Selenium WebDriver (with or without additional libraries such as DotNetSeleniumExtras.PageObjects) your testing tool of choice?
If so, I imagine built the page classes most likely look something like this:
A perfectly balanced test automation framework
In the case presented in the image above, we built a nice structure, with all page elements, actions associated with elements, implemented loads of assertions; tests are working like a charm. Suddenly, our QA manager comes by the desk and tells us that our perfectly balanced test automation framework should be shared with the rest of the QA team in order to get the team to start automating their test cases.
If test automation is not your strong suit yet, you might ask yourself: “Why is it possible to send keys action to a button?” And I have to agree it s a good question!
The answer:
Selenium is not making any distinction between various types of page elements. It looks at every element the same way and provides you with all available methods (actions).
We can perform send keys to a button and it will do nothing, it can even throw an error at us.
The next question is: Why not fix it and make the testing framework more user-friendly?
Let s look at the button element:
private IWebElement SearchButton => Driver.FindElement(By.XPath(“//input[@value= Search ]”));
The only action we perform on buttons is to click on it, but let s not forget that it s important to check if the button exists on the page in the first place.
That makes for two actions. Besides those two, we can come up with more actions like: is the button enabled, check the button text, color, etc.
Add a new class to the framework and name it Button.cs:
Define a class similar to the sample shown below:
Now, go back to a page class that has a button element defined, and update it with the new button element definition.
private Button SearchButton => new Button(By.XPath(“//input[@value= Search ]”));
Try to call the new methods:
Looks good, right? We eliminated actions that are not applicable.
We can now add more custom actions and repeat the same process for other elements such as inputs, drop-downs, check-boxes, etc.
Conclusion: Perfection is no small thing, but it s made up of small things
The good thing about the element models approach is that we use it for complex page elements, such as date pickers, multi-select drop-downs, image upload fields, etc.
After we build a model, we can use it within the entire testing framework and maintenance tasks are much easier since we are doing fixes or updates on a single place.
Till the next time Happy testing.