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.

[chimpmate]

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