Page Object Model, what is it ?
Benefits of using page object pattern:
Creating a reusable code that can be shared across multiple test cases.
Reducing the amount of duplicated code
Duplicate browser action.
Duplicate page action.
Duplicate element action.
If the user interfaces changes, the fix needs changes in only one place.
Starting a UI Automation in Selenium WebDriver is NOT a tough task. We just need to:
Find elements
Perform operations on it
Verify the result
Example of a simple test (without implementation of POM)
As you can see... all we are doing here is finding elements and filling values for those elements.
This is a small script, script maintenance looks easy now, but with time, the test suite will grow and we'll add more and more lines to your code... and things become tough.
The main problem with script maintenance is if 10 different scripts are using the same page element, with any change in that element, you need to change all 10 scripts, this is time-consuming and error-prone.
A better approach to script maintenance is to create a separate class file that would find web elements, fill them, or verify them.
This class can be reused in all the scripts using that element. In the future, if there is a change in the web element, we need to make the change in just 1 class file and not 10 different scripts.
Test case
Here is a test case that searches for a word in python.org website and ensures some results are found.
Page object classes
The page object pattern intends to create an object for each web page.
By following this technique a layer of separation between the test code and technical implementation is created.
The page.py
will look like this:
Page elements
The element.py
will look like this:
Locators
One of the practices is to separate the locator strings from the place where they are being used. In this example, locators of the same page belong to same class.
The locators.py
will look like this:
Principles
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 a 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.
separate the locator strings from the place where they are being used.
object repository is independent of test cases, so we can use the same object repository for a different purpose with different tools.
According to Page Object Model, we should keep our tests and element locators separately, this will keep code clean and easy to understand and maintain.
Test cases become short and optimized as we are able to reuse page object methods in the POM classes
Any change in UI can easily be implemented, updated, and maintained into the Page Objects and Classes.
Comments
Post a Comment