Guidelines for Page Object Model Frameworks

Page Object Model is one of the most commonly used design patterns in Selenium WebDriver. In this post, we look into some of the guidelines in using Page Object Model and Page Factory in Selenium.

Check out our Selenium WebDriver Framework Tutorial Series if you are new here.

Page Object Model Guidelines

What is Page Object Model in Selenium?

In Page Object Model(POM), usually the page or screen in the application is treated as objects (each page/screen has its own Class which is initialized for use). All the operations/functionalities offered by the page is available to the test scripts as methods of the Page Object class.
Using POM improves code re-usability, maintainability and readability.
There are ample tutorials on how to use Page Object Model, so I’m not covering that here.

Lets see some of the guidelines.

  • Use Base class

Its always useful to have a Base Page object class which contains the common functions on the page. For eg. let’s say we have an application where certain functionalities are common for all pages. In that case, these functionalities should can included in the base class. If the functionalities differ on certain pages, you can always override it in the corresponding Page Object class.

  • All operations should return the Page Object

If all operations return the page object instance, it would allow for chaining of methods.
eg. pageInstnace.doSomething().doSomeOtherThing();

  • Operations which performs Page Navigation should return the object of the next page.

Lets say an operation like submitting a form takes you to another page. In such cases, the method should return the instance of the next page as shown below.

SEE ALSO:   8 Selenium IDE Plugins you Should be Aware Of

If we do that, whenever we change the flow. eg. – a page returns another page instead of a different page as before, when we change the method signature, all the tests which depened on the previous signature will fail. That way, we can knw which tests will fail without running them.

  • Different Actions for Same Operation

If performing an operation can lead to different actions like submitting a form can take you to SuccessPage or FailurePage depending on the values, you should have different methods to handle each of them.

  • Only Expose Services in Page Object

Page Objects should expose only the services offered by the web page in question. Inner working of the page should not be exposed to the test. This make the test unaffected by the changes in implementation or inner flows.
WebDriver instance should not be exposed to the test script. This may not seem very flexible, but this forces you to implement the functionalities in your Page Object (as in previous point).

  • Page shouldn’t have any assertions

All assertions should be in tests. Right now you might be thinking of Page initialization where normally you would assert the title. But you could check the title and throw a custom Exception which would fail the test method. The reason this is done is to make sure that the Page Object is independent of any unit testing frameworks.

  • Segregate into Functionalities

For Single page application, segregate your page classes not based on pages but on functionalities. eg. Gmail -> based on mail list, compose, hangout etc.

SEE ALSO:   8 Reasons to Save your Automation Results in Database

What other guidelines would you suggest. Let us know in the comments below.

Further Reading:

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *