Exploring the concept of using nested page objects with Protractor

Question

Exploring the concept of using nested page objects with Protractor

The Inquiry:

How can we effectively define nested Page Objects in Protractor?

Situation:

Our webpage is complex, with various sections such as a filter panel, grid, summary part, and control panel. It's impractical to cram all element and method definitions into a single file and page object - it leads to confusion and maintenance challenges.

javascript selenium protractor pageobjects project-organization

Answer 1

Answer №1

When it comes to Page Objects and their maintenance, there is a general topic worth exploring. Recently, I came across a Page Object Design Pattern technique that caught my attention and made perfect sense to me.

Instead of creating child page objects within the parent page objects, a better approach would be to embrace JavaScript's Prototypal Inheritance. This method offers numerous benefits, but let me first demonstrate how we can implement it:

Let's begin by defining our parent page object ParentPage:

// parentPage.js
var ParentPage = function () {
// defining common elements
this.someElement = element(by.id("someid"));

// defining common methods
ParentPage.prototype.open = function (path) {
browser.get('/' + path)
}
}

module.exports = new ParentPage();  //export instance of this parent page object

We always export an instance of a page object rather than creating it in the test. Since we are working on end-to-end tests, we view the page as a stateless entity, similar to each stateless http request.

Now, let's move on to creating our child page objects ChildPage, utilizing the Object.create method to inherit the prototype of our parent page:

//childPage.js
var ParentPage = require('./parentPage')
var ChildPage = Object.create(ParentPage, {
/**
 * define elements
 */
username: { get: function () { return element(by.css('#username')); } },
password: { get: function () { return element(by.css('#password')); } },
form:     { get: function () { return element(by.css('#login')); } },
/**
 * define or overwrite parent page methods
 */
open: { value: function() {
    ParentPage.open.call(this, 'login'); // overriding parent page's open method
} },
submit: { value: function() {
    this.form.click();
} }
});
module.exports = ChildPage

Locators are defined within getter functions; these functions are evaluated when you access the property, not during object generation. This ensures that you request the element before performing any action on it.

The Object.create method returns an instance of the page so we can immediately start using it.

// childPage.spec.js
var ChildPage = require('../pageobjects/childPage');
describe('login form', function () {
it('test user login', function () {
    ChildPage.open();
    ChildPage.username.sendKeys('foo');
    ChildPage.password.sendKeys('bar');
    ChildPage.submit();
});

In the above code snippet, notice how we only require the child page object and utilize/override parent page objects in our specs. The following are the advantages of this design pattern:

Reduces tight coupling between parent and child page objects
Promotes inheritance among page objects
Lazy loading of elements
Encapsulation of methods and actions
Makes the element relationship cleaner and easier to understand, instead of
```
parentPage.childPage.someElement.click();
```

I stumbled upon this design pattern in webdriverIO's developer guide, where most of the techniques I explained are derived from. Feel free to explore it further and share your thoughts!

Answer 2

When it comes to Page Objects and their maintenance, there is a general topic worth exploring. Recently, I came across a Page Object Design Pattern technique that caught my attention and made perfect sense to me.

Instead of creating child page objects within the parent page objects, a better approach would be to embrace JavaScript's Prototypal Inheritance. This method offers numerous benefits, but let me first demonstrate how we can implement it:

Let's begin by defining our parent page object ParentPage:

// parentPage.js
var ParentPage = function () {
// defining common elements
this.someElement = element(by.id("someid"));

// defining common methods
ParentPage.prototype.open = function (path) {
browser.get('/' + path)
}
}

module.exports = new ParentPage();  //export instance of this parent page object

We always export an instance of a page object rather than creating it in the test. Since we are working on end-to-end tests, we view the page as a stateless entity, similar to each stateless http request.

Now, let's move on to creating our child page objects ChildPage, utilizing the Object.create method to inherit the prototype of our parent page:

//childPage.js
var ParentPage = require('./parentPage')
var ChildPage = Object.create(ParentPage, {
/**
 * define elements
 */
username: { get: function () { return element(by.css('#username')); } },
password: { get: function () { return element(by.css('#password')); } },
form:     { get: function () { return element(by.css('#login')); } },
/**
 * define or overwrite parent page methods
 */
open: { value: function() {
    ParentPage.open.call(this, 'login'); // overriding parent page's open method
} },
submit: { value: function() {
    this.form.click();
} }
});
module.exports = ChildPage

Locators are defined within getter functions; these functions are evaluated when you access the property, not during object generation. This ensures that you request the element before performing any action on it.

The Object.create method returns an instance of the page so we can immediately start using it.

// childPage.spec.js
var ChildPage = require('../pageobjects/childPage');
describe('login form', function () {
it('test user login', function () {
    ChildPage.open();
    ChildPage.username.sendKeys('foo');
    ChildPage.password.sendKeys('bar');
    ChildPage.submit();
});

In the above code snippet, notice how we only require the child page object and utilize/override parent page objects in our specs. The following are the advantages of this design pattern:

Reduces tight coupling between parent and child page objects
Promotes inheritance among page objects
Lazy loading of elements
Encapsulation of methods and actions
Makes the element relationship cleaner and easier to understand, instead of
```
parentPage.childPage.someElement.click();
```

I stumbled upon this design pattern in webdriverIO's developer guide, where most of the techniques I explained are derived from. Feel free to explore it further and share your thoughts!

Answer 3

Answer №2

The concept involves organizing the Page Object as a package - a directory with index.js serving as the main entry point. The parent page object would serve as a container for child page objects, each representing a distinct part of a screen.

Inside the index.js, the parent page object would hold all the definitions for the child page objects, like so:

var ChildPage1 = require("./page.child1.po"),
    ChildPage2 = require("./page.child2.po"),

var ParentPage = function () {
    // additional elements and methods can be defined here
    this.someElement = element(by.id("someid"));

    // child page objects
    this.childPage1 = new ChildPage1(this);
    this.childPage2 = new ChildPage2(this);
}

module.exports = new ParentPage();

Notice how this is passed into the constructors of the child page objects. This allows for seamless access to the parent page object's elements or methods if required.

The structure of a child Page Object would resemble:

var ChildPage1 = function (parent) {
    // definitions for elements and methods go here
    this.someOtherElement = element(by.id("someotherid"));
}

module.exports = ChildPage1;

Implementing this type of page object makes usage straightforward. By requiring the parent page object, you can easily access sub page objects using dot notation:

var parentPage = requirePO("parent");

describe("Test Something", function () {
    it("should test something", function () {
        // accessing parent
        parentPage.someElement.click();

        // accessing nested page object
        parentPage.childPage1.someOtherElement.sendKeys("test");
    });
});

The requirePO() function serves as a helpful import utility.

A snapshot of a nested page object directory structure from one of our automation projects:

https://i.sstatic.net/lvyHRm.png

Answer 4

The concept involves organizing the Page Object as a package - a directory with index.js serving as the main entry point. The parent page object would serve as a container for child page objects, each representing a distinct part of a screen.

Inside the index.js, the parent page object would hold all the definitions for the child page objects, like so:

var ChildPage1 = require("./page.child1.po"),
    ChildPage2 = require("./page.child2.po"),

var ParentPage = function () {
    // additional elements and methods can be defined here
    this.someElement = element(by.id("someid"));

    // child page objects
    this.childPage1 = new ChildPage1(this);
    this.childPage2 = new ChildPage2(this);
}

module.exports = new ParentPage();

Notice how this is passed into the constructors of the child page objects. This allows for seamless access to the parent page object's elements or methods if required.

The structure of a child Page Object would resemble:

var ChildPage1 = function (parent) {
    // definitions for elements and methods go here
    this.someOtherElement = element(by.id("someotherid"));
}

module.exports = ChildPage1;

Implementing this type of page object makes usage straightforward. By requiring the parent page object, you can easily access sub page objects using dot notation:

var parentPage = requirePO("parent");

describe("Test Something", function () {
    it("should test something", function () {
        // accessing parent
        parentPage.someElement.click();

        // accessing nested page object
        parentPage.childPage1.someOtherElement.sendKeys("test");
    });
});

The requirePO() function serves as a helpful import utility.

A snapshot of a nested page object directory structure from one of our automation projects:

https://i.sstatic.net/lvyHRm.png

Answer 5

Answer №3

Although I don't utilize Protractor, I have found success using a technique that involves dividing a page into components known as "Component Objects." By assigning scopes to each component, I am able to efficiently search for and add elements based on their specific scopes. This method allows me to easily reuse components across various pages.

For instance, when working with the webpage , I segment it into three parts: https://i.sstatic.net/joh0I.png These parts can be identified as: Header, SearchForm, Footer

The code snippet for each part could resemble the following:

class Header {
   public Header(SearchContext context){
       _context = context;
   }

   WebElement GmailLink {
       get {
           return _context.FindElement(By.CssSelector("[data-pid='23']"));
       }
   }
   WebElement ImagesLink {
       get {
           return _context.FindElement(By.CssSelector("[data-pid='2']"));
       }
   } 

   SearchContext _context;
}

class SearchForm{
   public Header(SearchContext context){
       _context = context;
   }

   WebElement SearchTextBox {
       get {
           return _context.FindElement(By.Name("q")):
       }
   }

   WebElement SearchButton {
       get {
           return _context.FindElement(By.Name("btnK")):
       }
   }

   SearchContext _context;
}
..

The corresponding code for the google.com page would look like this:

class GoogleComPage{
   WebDriver _driver;
   public GoogleCompage(driver){
       _driver = driver;
   }
   public Header Header{
       get {
           return new Header(_driver.FindElement(By.Id("gb")));
       }
   }

   public SearchForm SearchForm{
       get {
           return new SearchForm(_driver.FindElement(By.Id("tsf")));
       }
   }
}

Answer 6

Although I don't utilize Protractor, I have found success using a technique that involves dividing a page into components known as "Component Objects." By assigning scopes to each component, I am able to efficiently search for and add elements based on their specific scopes. This method allows me to easily reuse components across various pages.

For instance, when working with the webpage , I segment it into three parts: https://i.sstatic.net/joh0I.png These parts can be identified as: Header, SearchForm, Footer

The code snippet for each part could resemble the following:

class Header {
   public Header(SearchContext context){
       _context = context;
   }

   WebElement GmailLink {
       get {
           return _context.FindElement(By.CssSelector("[data-pid='23']"));
       }
   }
   WebElement ImagesLink {
       get {
           return _context.FindElement(By.CssSelector("[data-pid='2']"));
       }
   } 

   SearchContext _context;
}

class SearchForm{
   public Header(SearchContext context){
       _context = context;
   }

   WebElement SearchTextBox {
       get {
           return _context.FindElement(By.Name("q")):
       }
   }

   WebElement SearchButton {
       get {
           return _context.FindElement(By.Name("btnK")):
       }
   }

   SearchContext _context;
}
..

The corresponding code for the google.com page would look like this:

class GoogleComPage{
   WebDriver _driver;
   public GoogleCompage(driver){
       _driver = driver;
   }
   public Header Header{
       get {
           return new Header(_driver.FindElement(By.Id("gb")));
       }
   }

   public SearchForm SearchForm{
       get {
           return new SearchForm(_driver.FindElement(By.Id("tsf")));
       }
   }
}

Exploring the concept of using nested page objects with Protractor

Answer №1

Answer №2

Answer №3

Similar questions

Stop automatic selection of the last value in ng-options using AngularJS

What is the best way to stretch the background image across both the footer and navbar for my app?

Updating an array based on a condition and a nested array in Firestore

Is the combination of variable arrays and regular expressions causing issues?

Adjust the appearance of input fields that exclusively have the value "1"

Require assistance in getting a slider operational

Tips on traversing a JSON array in AngularJS using the ng-repeat directive

Struggling to Make Div Refresh with jQuery/JS in my Rails Application

The array is devoid of any elements, despite having been efficiently mapped

Verify record removal without a PHP click

Handling Promise Rejections in Puppeteer for Query Selector with Class条件

Node.JS function using try catch block

Can you smoothly scroll to an anchor and stop the animation mid-scroll?

Unable to retrieve variable declared externally from Switch Statement

The functionality of Bootstrap 4 tabs seems to be stuck and not responding

Add the item to a fresh array using the Ajax function

Understanding the NavigationContainer reference in Typescript and react-navigation

What is the method for adjusting the width of a v-card based on its height?

Send information to the server using the POST method

Encountering a problem when trying to find an element with xpath in Selenium 3