Automation Abstractions: Page Objects and Beyond – Conference Talk

I presented “Automation Abstractions: Page Objects and Beyond” as a conference talk at Star West 2014 and Oredev 2014

Essentially the same talk, but Oredev had a slightly smaller timeslot for the talk, so I summarised the verbage a little.

I have uploaded the slides to slideshare

And the source code is on github.com/eviltester/automationAbstractions

The talk was filmed and recorded by Oredev, unfortunately the audio doesn’t appear to have recorded properly and is very quiet in their released vimeo video..

However, I have subsequently amended their video and re-processed the audio so you can hear it, and released it on YouTube and you can watch it below.

This entry was posted in Conferences, Practices. Bookmark the permalink.

13 Responses to Automation Abstractions: Page Objects and Beyond – Conference Talk

  1. Pingback: Testing Bits – 11/2/14 – 11/8/14 | Testing Curator Blog

  2. jose says:

    Hi,

    I tried to watch the video, but the audio is really low… is there another link available?

  3. shawn says:

    Great talk! — I nearly agreed with all your points — the abstraction level(s) helps drive test readability, clarity and intent.

  4. Kent Wood says:

    Excellent and inspiring as always, Alan. Your discussion both validated some choices I’ve made and challenged me to look more closely at others. I have also become very fond of the POJO approach, and have weaned myself of of PageFactory and @FindBy after finding that, with our app at least, it was interfering with my need to devise more elaborate wait strategies to avoid stale elements and such on a very Ajax intensive site.

    My current method for abstracting web elements in a page object is to use the By object:

    public By by_homeButton = By.cssSelector(“[data-section=’Home’]”);

    …instead of the PageFactory approach:

    @FindBy(css = “[data-section=’Home’]”)
    public WebElement elem_homeButton;

    I can then pass that By object as an argument into all sorts of methods without ever having to worry about whether the destination method is geared for xpath, css or whatever. It’s been a game changer for me in terms of keeping my page objects readable and as flexible as possible.

    • Alan says:

      Hi Kent, that seems like a good way to open up the locators to external objects. I periodically make fields public like that. I try to make fields `final` when I do, so that I don’t incur the wrath of developers around me. And I can see that making the locators public could allow you to create a physical page object with minimal abstractions and use it independently or in a ‘functional’ page object.

      Thanks for sharing the example.

      • Kent Wood says:

        What is the advantage of making them Final? I don’t quite understand what the effect on other dev’s would be in this case. I work on my codebase alone, so there’s a great deal I haven’t had to take into account in terms of ‘playing nicely with others’. 🙂

        • Alan says:

          Normally fields aren’t made public, and you wrap them with methods to change them. If you make them final then they can’t be re-allocated once they’re instantiated so there is less reason to wrap them with methods.

  5. Kent Wood says:

    Just wanted to provide some examples I forgot to put in the above comment. These are methods I have tailored to receive a By object as an argument. I have a dependableClick() method to deal with the wait strategies in my own way (PageFactory’s way didn’t work in my case and to be honest I don’t really know Java well enough to understand how to extend PF’s methods to tailor them for my needs). The other 2 methods are pretty self explanatory, a wait-for-presence and a method to input text to an element (encapsulating all the logic needed to wait, clear existing text and so on).

    dependableClick(by_button1);
    waitForElementPresence((by_button3));
    inputTextToElement(by_firstName, “John”);

    • Alan says:

      That’s interesting. If the methods are all similar then I might be tempted to create something like an AppSpecificWebElement class which I instantiate with the By approach that you documented previously. Then in the code I might have:

      AppSpecificWebElement button1 = new AppSpecificWebElement(by_button1);
      button1.click();

      where the click above is the code in your dependableClick method

      or possibly, if I didn’t want to assign to a variable all the time, I might use a static method `for to construct the object:

      AppSpecificWebElement.for(by_button1).click()

      That way I could continue to expand the AppSpecificWebElement for additional methods that require app specific treatment or synchronisation.

      It isn’t a full WebElement abstraction, but it would isolate the code.

      Thanks again. Its always great to see how other people are implementing their abstraction layers to get alternative ideas. Thank you.

  6. Jagori says:

    Hi Alan,Thanks for explaining the page object concept so well. I had some doubts re the component abstraction. What exactly can be treated as components ,I understood header,footer/any widgets on a page can be treated that way. So say I have a long form or a single page having few links on it which when clicked opens layers in foreground and the background form gets disabled. The layers that open up are again short forms with a submit button. Is it ok to consider these layers as components on parent background page?
    Or should I be using navigation objects in this case?
    Thanks,
    Jagori

    • Alan says:

      I think the words “Page Object” can lead to confusion.

      I tend to use them to mean a physical abstraction layer that represents something on the page and my interactions with it. Sometimes the ‘interactions’ might even be in a separate object.

      In the example you give, I would probably consider the layers as page objects. I probably would not represent them in a navigation because they appear, disappear via interaction rather than navigation i.e. I can’t navigate directly to them.

      So I might (keeping it simple) do something like the following.

      page.submitForm(“mydetails”);

      div = wait.until(new DivOverLayAppears());

      div.interact();

      etc.

      Does that make sense?

      Main points are – synchronisation, separate ‘page’ object, no navigation.

      I might live with this for a while and then see if I need to refactor it or amend it into a different abstraction level.

  7. Pingback: Question: What is the best Page Object framework for Java? » Selenium Simplified

Leave a Reply

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