Page Object Model: How much abstraction is necessary?



  • So i've been working on a Page Object Model framework for a large web application for our current company. It's the first time i've made my own framework and implemented the page object model. Im using Ruby w/Capybara and Selenium-Webdriver for my language/driver of choice.

    Currently i've divided each page (or obvious "section of the site") into a class file. This class file has methods for just about everything (or an API of sorts). The problem i've ran into is that I am literally writing a method for every single thing....and i've came across 2 ways people seem to do this:

    Lets pretend for a section/page of the site is a widget creation form, the widget has a name/description and some sort of "type" dropdown. Also a save button to save the widget.

    Option A (Which is what i've done so far): Make a method for each element (the save button, called save_widget, all the different inputs, etc...)

    Option B: Have getter and setter methods for each element, then a larger method which uses these private getter and setter methods.

    With Option A my test scripts end up being longer, and honestly not much different than using selenium calls themselves.

    Option B would probably call one method (Such as create_widget which would pass in multiple items which that method would call all the smaller getter/setter methods). This would make the test script MUCH shorter and more abstracted. However the getter/setter methods would probably take more actual writing for the page objects themselves (but possibly easier to maintain).

    Is there a certain style that favors one over the other? The more I think about it the more Option B seems better...but I wonder if in this case abstraction is a good thing.



  • Both of your options listed can work. Though, as you mentioned, option A is only slightly better than not using POM.

    Every time I do test automation, it's always been on teams that have no automation, so I'm always creating frameworks from scratch.

    In my experience, I favor option B that you have listed. This level of abstraction and encapsulation works best for long term maintenance. And, if there is more than 1 person writing tests, they only need to be concerned with what methods to use and not have to worry about how to use getter/setters. This also allows you to create overloaded methods, when needed, and use the same elements in your getter/setter. Option B allows for more customization and control.

    Test specs should be short and contain your data, your asserts, and any class/method calls to implement the test. While your POMs contain your elements and methods on how to use the elements.

    Edit: Note, not all languages support method overloads. An example of overloaded method looks like:

    public void login () {}
    public void login (username, password) {}
    

    Same name is used for both methods, the take different parameters, and may have different logic/steps to perform. In this case, maybe the first method is used to login as a guest, where the second supports login credentials.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2