PageObject use – is it rewarding?

PageObject use – is it rewarding?

In this post, I want to show you the principles of the most useful pattern for end-to-end testing. I will use Selenium for all examples. I assume that you know this tool. It would be easier to explain some things.

The biggest problem with Selenium

Selenium WebDriver gives us powerful tools for writing end-to-end tests. We can imitate the user behavior on every aspect. However, it doesn’t come without some pain. It has several problems that testers must deal:

  • code repeats between different tests
  • it is hard to read long test scenarios
  • tests are high sensitive to changes in the page structure

The more tests you write, the more painful would be above problems. We can reduce them in many mans, but it exists one recommended method, which can help you with most of them.

Page Objects pattern

It is a design pattern considered as a best practice during test creation process. It consists of one fundamental concept. Actions and data available on a web page can be represented as class members. Therefore we can manipulate the page just by using class and its properties.

Let’s take a Google Translate Page as an example.

For this page, we should create following Page Object class.

public class TranslatePage
{
    private IWebDriver _driver;

    public TranslatePage(IWebDriver driver)
    {
        this._driver = driver;
    }

    public IWebElement SourceText {
        get {
            return _driver.FindElement(By.Id("sourceTextId"));
        }
    }

    public IWebElement TargetText {
        get {
            return _driver.FindElement(By.Id("targetTextId"));
        }
    }

    public IWebElement TranslateButton {
        get {
            return _driver.FindElement(By.Id("translateButtonId"));
        }
    }
}

As you can see, it consists of 3 properties. Each one corresponds to one functional element on the page. If we want to use these elements in our test we can use suitable properties.

var translatePage = new TranslatePage(driver);

translatePage.SourceText.SendKeys("cat");

translatePage.TranslateButton.Click();

Assert.AreEqual(translatePage.TargetText.Text, "kot");

As you see if we have page objects created earlier and we want to write next test scenarios, it will be a piece of cake.

Light and dark sides of Page Objects

This pattern looks excellent at first sight. After working a bit longer with it, we can notice additional advantages.

  • easy to maintenance – we have one place to define selector for the particular element,
  • low level of redundancy – we don’t have to repeat the FindElement code,
  • scalable solution – when we create a Page Object, we can use it without additional time effort,
  • a natural approach to programmers – it is very easy for developers to set up and use programming structures,
  • encapsulate functionality – it separates application modules. If we modify some module, there is a limited space when we need to check selectors.

However, it also comes with some disadvantages. There are mainly related with a time cost.

  • the higher cost of Page Objects creation – initial cost of creation necessary Page Objects is higher than creating a regular test. It pays back in future.
  • requires programming skills – due to use class structures

When it pays back?

It is the most important question for this pattern. It all depends on different things.

If we want to create just a few test cases, probably it won’t be many profits from using Page Objects.

In the other case, if we plan to test multiple test cases for a simple page it worth to use it. In that case, we should start creating them at the beginning of end-to-end testing and use this approach entirely.

The situation changes when we decide to use Page Objects generators. But this is a topic for next post.

Sign up for free end-to-end testing training

Learn how to create end-to-end tests for your applications from the beginning to mobile testing
Name
Email address
End-to-end testing is a great improvement in quality testing automation. It reflects the user experience the most of all tests.
This book is a complete guide to Selenium tools. Both for beginners and experienced developers.
It just makes sure that system works fine, saving your time after all.

See more

  • Ok Tober

    If such text fields are constantly repeating on different pages – I would additionally create (sorry for Java)
    1. abstract “TextFieldObject” class with default methods
    getText();
    getWebElement() ;
    probably – getButtonsAmount() – in case when we have tests where we check amounts of buttons in these fields.

    2. and classes
    SourceTextField extends TextFieldObject; (setText(), clearText(), clickButton(micro/volume,etc))
    TargetTextField extends TextFieldObject; …
    with all methods needed for each class
    and in test i’ll use it like:

    translatePage.getSourceTextField().setText(“blabla”).clickButton(Buttons.VOLUME);
    translatePage.clickTranslateButton();
    String translation = translatePage.getTargetTextField().getText();
    assertEquals(translation, expectedTranslation, “Heh, your eng is bad bro!” )

    • suvroc

      I definitely agree with you. If we can notice similar components on several pages it would be useful to create PageObject (it should be named ComponentObject) for each of them.

GET YOUR EMAIL UPDATES

Get great contents delivered straight to your inbox everyday, just a click away, Sign Up Now.
Name
Email address