Do I need the PageObjects design pattern or not?

Question

Right now I have a Selenium WebDriver framework that looks like this (vastly simplified):

• \app_func.py -- app_func has the web app's "actions", such as "save a new search"

• \app_data.py -- app_data has common assertions, such as if I re-use some test data, it'll store that data's document count, so I can do assert count == app_data.big_zip_file in my test file

• \util.py -- util has common, application-neutral functions like wait_for_text

• \setup.cfg -- setup contains all the server info, etc.

Then I have a tests dir:

• \tests\upload_big_zip -- each test.py file imports app_func, app_data, util.

And then a test looks like:

app_func.upload_data('big.zip')
app_func.save_a_search('search terms', app_data.big_search_hits)
app_func.verify_search_hits

So I get the key benefits of the PageObjects pattern -- like being able to easily update save_a_search if the developers change the UI. But it's a much "flatter" structure than the OO PageObjects. I can't yet wrap my mind around the pattern.

Is there any reason I should build up a new structure based on PageObjects? What I'm looking for is, what are the benefits compared to my approach?

Answer 1

There are times when using the Page Object Pattern makes a lot of sense and times where it doesn't make as much sense. If you have a web application where it is basically one single dynamic page then it makes less sense, however you can still use "page" objects that are really more like "section" objects for common pieces, for example if you have a Left Nav, you could create a page object for it and then another for a calendar section or whatever sections you have on the page that make sense to break out.

The main things you get from the page object pattern are

1. The ability to have one location where you identify elements that exist on a page and where helper functions applicable to that page exist so changes only happen in one place instead of all of your test cases.
2. It acts as an abstraction layer on top of Selenium so if changes come to selenium you can update your pages instead of every test case.

You can also build an abstraction layer on top of Selenium and have your page objects interact with that to further protect yourself from changes.

If the elements for the AUT(application under test) and helper functions for your AUT exist in app_func and it is a simple enough structure then it seems like you are running into a situation where the page object pattern isn't as useful. It's up to you to decide whether it is complex enough to break out into sections.

Answer 2

It depends upon how your site is constructed. If your site's pages follow some common patterns, and if those patterns are stateful, then it may be useful to model the pages as objects. Otherwise, it may not be worth the trouble.