Jim Lynch Codes
  • Blog
  • About Jim

Writings about one coder's stories & experiences.

The Protractor Page Object Pattern

4/25/2016

0 Comments

 
The Page Object Model pattern was a thing long before Protractor and even Testacular were ever created. POM is a design pattern for Selenium WebDriver, and it is basically a way to structure your e2e test code so that it is more maintainable, readable, and reusable. In Protractor, we code in JavaScript, but what we are doing is very similar to the code of various WebDriver languages; selecting things from the DOM. This DOM selection code comes up quite a lot, and the POM allows you to define variables in another file so they would only need to be changed in at most one place. Let's take a look at an example of protractor tests without the POM:
By the way, you can also find this code on github here.
noPom.spec.js
(function() {
  'use strict';
  var page;
  describe('Button Click Example', function () {

    beforeEach(function() {
      browser.get('http://localhost:3000/');
    })

    it('should find the \"calculator-title\" element', function() {
      expect(element(by.css('.page-title')).isPresent()).toBeTruthy();
    });

    it('should not find elements that don\'t exist', function() {
      browser.get('http://localhost:3000/');

      expect(element(by.css('nonexistent-element')).isPresent()).toBeFalsy();

    });


    it('should not have clicked text visible to start', function() {
      expect(element(by.id('clicked-text')).isPresent()).toBeTruthy();
      expect(element(by.id('clicked-text')).isDisplayed()).toBeFalsy();

    });

    it('should show the text after the button is clicked', function () {
      element(by.css('.my-button')).click();
      expect(element(by.id('clicked-text')).isDisplayed()).toBeTruthy();
    });

    it ('should show correct text after button is pressed once.', function() {
      element(by.css('.my-button')).click();
      expect(element(by.id('clicked-text')).getText()).toEqual('The button has been clicked 1 time.');
    });

    it('should show the correct text after button is clicked 5 times.', function () {
      element(by.css('.my-button')).click();
      element(by.css('.my-button')).click();
      element(by.css('.my-button')).click();
      element(by.css('.my-button')).click();
      element(by.css('.my-button')).click();
      expect(element(by.id('clicked-text')).getText()).toEqual('The button has been clicked 5 times.');
    })

  })


})();
You ca see that in this code there is a whole lot of "element(by." code, and then making any changing to your scss files may mean one or more epic find/replace's need to be done. It's just straight up duplication really, and changing this code to use POM allows you to refactor it away. 

What Exactly is POM?

In the page object model pattern, you still have a .spec.js file that is a describe full of it's with some beforeEach's just like any other test, but here you now have an addition .po.js file that sets common DOM selection to variable of one a single "page object". Since Protractor runs on node.js we can make use of require to pull in this page object to our .spec.js class in the beforeEach function. Here's how it might look:
pomExample.po.js
pomExample.spec.js
(function () {
     'use strict';
     var page;
     describe('Button Click Example', function () {

          beforeEach(function () {
               browser.get('http://localhost:3000/');
               page = require('./main.po');
          })

          it('should find the \"calculator-title\" element', function () {
               expect(page.pageTitle.isPresent()).toBeTruthy();
          });

          it('should not find elements that don\'t exist', function () {
               browser.get('http://localhost:3000/');

               expect(page.nonexistentElement.isPresent()).toBeFalsy();

          });

          it('should not have clicked text visible to start', function () {
               expect(page.clickedText.isPresent()).toBeTruthy();
               expect(page.clickedText.isDisplayed()).toBeFalsy();

          });

          it('should show the text after the button is clicked', function () {
               page.myButton.click();
               expect(page.clickedText.isDisplayed()).toBeTruthy();
          });

          it('should show correct text after button is pressed once.', function () {
               page.myButton.click();
               expect(page.clickedText.getText()).toEqual('The button has been clicked 1 time.');
          });

          it('should show the correct text after button is clicked 5 times.', function () {
               page.myButton.click();
               page.myButton.click();
               page.myButton.click();
               page.myButton.click();
               page.myButton.click();
               expect(page.clickedText.getText()).toEqual('The button has been clicked 5 times.');
          })

     })

})();
Withe POM setup changes to the css require only one change (per style changed) in the .po.js file and no changes to the spec file. It also "lightens up" the spec file by taking out the DOM selection code with all its annoying parentheses. Learn to love the page object model for Protractor testing. It'll serve you well!

Bonus Video

Here's a nice video that explains the Page Object Model pretty well. Unfortunately, it's actually about selenium WebDriver and not Protractor so the presenter uses all Java examples instead of Angular Javascript. However, the concepts are the same, and it's not all that hard to see how most of his WebDriver automation presentation applies to your Angular e2e tests as well. 
0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    ​Author

    Picture
    The posts on this site are written and maintained by Jim Lynch. About Jim...
    Picture
    Follow @JimLynchCodes
    Follow @JimLynchCodes

    Categories

    All
    Actionscript 3
    Angular
    AngularJS
    Automated Testing
    AWS Lambda
    Behavior Driven Development
    Blockchain
    Blogging
    Business Building
    C#
    C / C++
    ClojureScript / Clojure
    Coding
    Community Service
    CS Philosophy
    Css / Scss
    Dev Ops
    Firebase
    Fitness
    Flash
    Front End
    Functional Programming
    Git
    Go Lang
    Haskell
    Illustrations
    Investing
    Java
    Javascript
    Lean
    Life
    Linux
    Logic Pro
    Music
    Node.js
    Planning
    Productivity
    Professionalism
    Python
    React
    Redux / Ngrx
    Refactoring
    Reusable Components
    Rust
    Security
    Serverless
    Shell Scripting
    Swift
    Test Driven Development
    Things
    TypeScript
    Useful Sites
    Useful Tools
    Video
    Website Development
    WebStorm
    Writing

    Archives

    March 2023
    August 2021
    February 2021
    January 2021
    October 2020
    September 2020
    May 2020
    April 2020
    February 2020
    January 2020
    December 2019
    October 2019
    September 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    May 2017
    April 2017
    March 2017
    February 2017
    January 2017
    December 2016
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015

    RSS Feed

  • Blog
  • About Jim
JimLynchCodes © 2023