Helper Classes for SlowLoadableComponent Page Objects

I generally caution against ‘Helper’ classes and Static Helper classes when I’m consulting for automation.

e.g. PageObjectHelper, or ApplicationHelpers, or StringHelpers etc.

Because ‘generally’, these ‘Helper’ objects mean “We created a class to dump stuff in because we couldn’t figure out how to model our abstraction layers” and often, people then dump more and more methods into them such that they become an undisorganized and unmaintainable mess.

Just so you know where I’m coming from here.

WebDriver has a ‘good’ Helper class in the form of the ExpectedConditions class. Every static method on it returns an expected condition which I can then use in a WebDriverWait, and these expected conditions represent very common wait conditions that I use across many projects.

Since I’ve started using the SlowLoadableComponent approach for most of my Page Objects recently, I have written a lot of code that looks like this:

    protected void isLoaded() throws Error {
                throw new Error("field is not displayed");
        }catch(WebDriverException e){
            throw new Error("field is not displayed", e);

And it starts to make my Page Objects look pug ugly.

I have started to take a leaf out of the ExpectedConditions class rule book and have been creating an IsLoaded ‘helper’ Class

I have used 3 main approaches for this:

  • A Fluent Class
  • A set of Static methods
  • Combined Fluent And Static

In WebDriverExperiments on GitHub I have added a basic propranolol online canadian pharmacy ‘fluent’ class which I would use like this:

    protected void isLoaded() throws Error {

               whenElementIsVisible(SEND_BUTTON, "Send Button").
               whenElementIsEnabled(SEND_BUTTON, "Send Button").
               whenElementIsVisible(NAME_FIELD, "Name Input").
               whenElementIsEnabled(NAME_FIELD, "Name Input");

You can see I create an IsLoaded object via a factory method and then have the try/catch/’throw error’ stuff abstracted away on the IsLoaded methods.

Sometimes I make these static so the call would look more like this:

IsLoaded.whenElementIsVisible(driver, SEND_BUTTON, "Send Button");

And sometimes I mix it up so I can call Static methods, or use the fluent style on the above object.

I might even write code that allows me to write the following:

  and().thisElement(SEND_BUTTON, "Send Button").
  and().thisElement(NAME_FIELD, "Name Input").

The above is just a thought experiment, but I haven’t been annoyed enough with the repeated parameters in the code I’ve uploaded to github to pursue it yet.

I think that this ‘Helper’ object is well enough named, and tightly enough scoped that it won’t cause a problem, so it doesn’t trigger my ‘Ugh, helper Class’ response.

I think a few more production usages and I’ll settle on a style that I’ll use as a default. At the moment, the ‘non-static’ approach is winning, hence no static example in the github code.

But what do you think? Leave a comment if you have an alternative modelling approach.



This entry was posted in Practices, Selenium Simplified Blog, WebDriver. Bookmark the permalink.

2 Responses to Helper Classes for SlowLoadableComponent Page Objects

  1. Sergei says:

    Unfortunately, all bitbucket links returns 404 error ((

Leave a Reply

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