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.save_a_search('search terms', app_data.big_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?

  • Oh and hey, I'll be presenting at the PDX selenium meetup tonight if you're there and can answer additional questions you might have about this.
    – Sam Woods
    Jun 22 '12 at 0:08
  • Oh, you're THAT guy! Ha. Yep, I'm leaving for the MAX to head out to Lucky Lab in just a few minutes!
    – Aaron
    Jun 22 '12 at 0:24

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.

  • Yeah, I'm already getting both benefits of your #1. Our app does have multiple sections (it's not a single page app), and I have 500 lines of functions in app_func to perform actions on those pages. I can see your point about #2, though. There's probably some brittleness in my app_func if Selenium were to change how it did things.
    – Aaron
    Jun 22 '12 at 0:23

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.