Creating Selenium test
cases can result in an unmaintainable project. One of the reasons is that too
many duplicated code is used. Duplicated code could be caused by duplicated
functionality and this will result in duplicated usage of locators. The
disadvantage of duplicated code is that the project is less maintainable. If
some locator will change, you have to walk through the whole test code to
adjust locators where necessary. By using the page object model we can make
non-brittle test code and reduce or eliminate duplicate test code. Beside of
that it improves the readability and allows us to create interactive
documentation. Last but not least, we can create tests with less keystroke. An
implementation of the page object model can be achieved by separating the
abstraction of the test object and the test scripts.
Note: We will follow the same example which we have used in First Test Case. Let’s assume it our base test case and implement the Page Object Model (POM) in it.
Creating Selenium test
cases can result in an unmaintainable project. One of the reasons is that too
many duplicated code is used. Duplicated code could be caused by duplicated
functionality and this will result in duplicated usage of locators. The
disadvantage of duplicated code is that the project is less maintainable. If
some locator will change, you have to walk through the whole test code to
adjust locators where necessary. By using the page object model we can make
non-brittle test code and reduce or eliminate duplicate test code. Beside of
that it improves the readability and allows us to create interactive
documentation. Last but not least, we can create tests with less keystroke. An
implementation of the page object model can be achieved by separating the
abstraction of the test object and the test scripts.
Note: We will follow the same example which we have used in First Test Case. Let’s assume it our base test case and implement the Page Object Model (POM) in it.
Note: We will follow the same example which we have used in First Test Case. Let’s assume it our base test case and implement the Page Object Model (POM) in it.
How to do it…
1. Create a ‘New Package’ file and name it as ‘pageObjects’, by right click on the Project and select New > Package. We will be creating different packages for Page Objects, Utilities, Test Data, Test Cases and Modular actions. It is always recommended to use this structure, as it is easy to understand, easy to use and easy to maintain.
2. Create a ‘New Class’ file and refer the name to the actual page from the test object, by right click on the above created Package and select New > Class. In our case it is Home Pageand LogIn Page.
3. Now create a Static Method for each Element (Object) in the Home Page. Each method will have an Argument (driver) and a Return value (element).
Driver is being passed as an Argument so that Selenium is able to locate the element on the browser (driver).
Element is returned, so that an Action can be performed on it.
Method is declared as Public Static, so that it can be called in any other method withoutinstantiate the class.
Follow the same rule for creating LogIn Page class.
4) Create a ‘New Class‘ and name it as POM_TC by right click on the ‘automationFramework‘ Package and select New > Class. We will be creating all our test cases under this package.
Now convert your old First Test Case in to the new Page Object Model test case.
You will notice that once you type Home_Page in your test script and the moment you press dot, all the methods in the Home Page will display. We can expose methods in order to reduce duplicated code. We are able to call these method multiple times. This will ensure a better maintainable test code, because we only have to make adjustments and improvements in one particular place.
Your Project explorer window will look like this now.
It is advisable to maintain Page Objects Repository in the same way QTP maintain its Repository. Please visit Selenium Object Repository section to learn more.
No comments:
Post a Comment