One of the most significant parts of comprehensive user interface (UI) test automation is the page object pattern. Despite the fact that it has been available for more than 15 years, eight out of ten test automation engineers disregard it in my experience. Ignoring page object patterns should be added to your list of test automation blunders you don’t want to make, given their utility and efficacy.
Page object patterns reduce redundancy by adding a layer of abstraction between your automated functional tests and the target web page. To put it another way, you construct a single class for a single web page, then use that class in your automated functional test to interact with the web page just like you would manually.
This is a tried-and-true pattern that works—but only if it’s followed correctly. Page object patterns are frequently used by the solution architects with whom I deal, and it’s easy to see why: it’s a simple, effective approach that produces results.
It’s easy to fall into the trap of believing that all good solutions must be difficult, however, this isn’t the case with page object patterns and test automation. Add this to your list of test automation resources because the simplest solutions are typically the best.
Here’s what you need to know about page object patterns so you can use them effectively in your automation projects.
1. Create a great name for your page object class
Make certain that the name you chose makes it crystal apparent what is contained within that page object. If you can’t, your page object is probably doing too much.
Take a look at the SauceDemoLoginPage below, which is a mock-up of an app’s login page. What kind of methods and properties would you expect to find within based on the class name?
What you’ll find inside the SauceDemoLoginPage class is unlikely to surprise you. Consider the case if the same code was used in a class called SaucePageObject (). You’d have no idea what this class represents when you read it, and you could be startled by what you find inside.
2. The page class should only contain methods for interacting with the HTML page or component
Only public methods that an end-user can utilize to interact with your web application should be allowed in your page objects. Take a look at the HTML page below. Only two actions are available to the end-user: Open() and Login (). As a result, SauceDemoLoginPage.cs has been implemented.
The app’s end-user does not use ConnectToSQL(), OpenExcel(), or ReadPDF() (). As a result, these methods should not be used in automated UI tests. As a result, they cannot be made publicly available in your page objects.
Consider the case where you have 50 tests that use OpenExcel (). As you gain experience and find that Excel isn’t the greatest place for your test data, you may opt to use data from an API, JSON, or CSV instead.
You’d have to update these 50 tests to utilize the new approach at that point, but not because the application’s requirements had changed. Instead, you’ll need to alter them because your test exposed methods that have nothing to do with the functionality of the object.
3. The page class should contain properties and methods, or be composed of objects that expose access
You can interact with the program through a single interface: the page object, by using page objects. The SauceDemoLoginPage class is used to interact with the login page.
For instance, you could want to use SauceDemoLoginPage to log in.
“username”, “password”); Login(“username”, “password”);
In this scenario, you should avoid putting the locators in a distinct class because they aren’t necessary and will only confuse your code.
Many sources claim that by separating methods and properties for a page object, the single responsibility principle will be maintained (SRP). That, however, is incorrect. The obligation in SRP is delegated to an actor whose changing needs will force you to update your page object. If there are multiple such actors, the module or page object has multiple responsibilities.
Only the developer, strictly speaking, has the power to force you to modify your class. No one else would be required to change HTML elements without simultaneously changing HTML methods.
Finally, it’s vital to keep your locators and methods for a page object separate. It’s pointless; it’s a case of over-optimization. A page, on the other hand, could be made up of several components that are important to the page object.
4. A page object doesn’t have to be an entire HTML page and can be a small component
This is referred to as “composition” by programmers. The goal is to encourage pages to compose rather than rely on inheritance. You’ll discover how to use composition to make page objects that are cleaner and tighter in the video below.
The Automobile is made up of an Engine and Wheels in this example, and the Engine is a class that retains the operations and properties of a car engine.
You may also break up your large page objects into multiple components in the same way. Notice how the products page is made up of a CartComponent and a FooterComponent in the example below. The CartComponent handles shopping cart activities, whereas the FooterComponent handles the application’s footer.
Take note of how this ProductsPage adheres to all three standards. There are no surprises in terms of what’s inside the class or the publicly accessible methods.
Make the most of your page objects
Simple page objects are a strategy that is sometimes overlooked. They’re highly effective and simple to use, and they produce code that’s simple to read and maintain. Page object patterns have been around for a long time and have proven to be effective. All you need to know is how to put them to work for you.
For more info: https://www.qaaas.co.uk/testing-services/
Also Read: https://www.guru99.com/software-testing.html