With time, increasing in the functionality of software products, test automation script also increases, so we tend to develop robust frameworks which are simple and easy to maintain our test scripts.
Traditional framework
in traditional frameworks, we normally divide test scripts based on the modules and create separate test script files for each module,
To understand the scenario, let’s say we have “Next” button in each page, and each 2 page are one one modules, then each module we locate “Next” button and click
so we normally locate an element whenever we need to act on, and repeat the same at every module we need,
so what’s the Problem!
With this above implementation, we are declaring a single element multiple places, let’s say “Next” button got changed to “MoveNext“, then we need to check all our modules and change he locator,
[this is what we are talking with webElements, but we have even same problem with methods, like a method to print report each page.]
What is PageObjectModel
Every object and related actions (operations) of each webpage should be in one class, that simple!!
e.g: in our web application, we have 10 webpages, then we will have 10 page object classes.
now test script / test cases can access these page object classes whenever needed.
so what’s the benefit!
- If we have separate classes for each webpage’s objects and operations, then we will declare/locate each object once through out the framework [avoids duplication].
- now if we want to change any object locator or name, then we need to go to that one respective page and change it once.
A typical POM (PageObjectModel) framework
This above is just a snap of simple framework, we can customize as our needs, even we can have folders for server.exe files, excel files, library files etc… under project folder for ease of access.
To support and extend PageObjectModel, introduced a new concept PageFactory.
click PageFactory post for more details.
hi
please highlight the menu item which one is clicked