There is some disagreement over the taxonomy of test types, but with AngularJS, the tests will fall into two types: unit tests and end-to-end tests. Unit tests are the black-box-style tests where a piece of the application is isolated, has external components mocked out for simulation, is fed controlled input, and has its functionality/output verified. End-to-end tests simulate proper application-level behavior by simulating a user interacting with components of the application and making sure that they operate properly by creating an actual browser instance that loads and executes your application code.

Once the testing is set up, running and evaluating your test suite is simple. Karma and Protractor will run separately, one after the other (depending on which comes first in the grunt test task). Each of them will spawn some form of browser in which they will perform the tests. Karma will generally utilize PhantomJS to run the unit tests in a headless browser, and Protractor will utilize Selenium WebDriver to spawn an actual browser instance (or instances, depending on how it is configured) and run the end-to-end tests on your actual application that is running in the browser, which you will be able to see happening if it is running on your local environment.

After running the test suite, the console output of Grunt will inform you of any test failures and other metadata about the test run. The output of a successfully run test suite, both unit tests and end-to-end tests with no errors, will include something similar to the following:

Running "karma:unit" (karma) task
INFO [karma]: Karma v0.12.23 server started at http://localhost:8080/
INFO [launcher]: Starting browser PhantomJS
INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket sYgu4c8ZxNFs73zBe_xq with id 75044421
PhantomJS 1.9.7 (Mac OS X): Executed 3 of 3 SUCCESS (0.017 secs / 0.015 secs)

Running "protractor:run" (protractor) task
Starting selenium standalone server...
Selenium standalone server started at http://192.168.1.120:59539/wd/hub
.....

Finished in 7.965 seconds
5 tests, 19 assertions, 0 failures

Shutting down selenium standalone server.

Done, without errors.
Total 19.3s

Error messages in AngularJS are always getting better, and the AngularJS team is actively working to make failures easier to diagnose by providing detailed error messages and better stack traces. When a test fails, the string identifiers that Jasmine allows you to provide while writing the tests will quickly allow the developer who is running the tests to identify the problem. This is shown in the following error output:

Running "karma:unit" (karma) task
INFO [karma]: Karma v0.12.23 server started at http://localhost:8080/
INFO [launcher]: Starting browser PhantomJS
INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket HVy4JBfIMACzUGR8gPFY with id 29687037
PhantomJS 1.9.7 (Mac OS X) Controller: HandleCtrl Should mark handles which are too short as invalid FAILED
    Expected false to be true.
PhantomJS 1.9.7 (Mac OS X): Executed 3 of 3 (1 FAILED) (0.018 secs / 0.014 secs)
Warning: Task "karma:unit" failed. Use --force to continue.

Aborted due to warnings.

Selenium WebDriver (also referred to as just "WebDriver") is a browser automation tool that provides faculties to script the control of web browsers and the applications that run within them. For the purposes of end-to-end testing, the test runner manifests as three interacting components, as follows:

Protractor is built on top of WebDriver. It acts as both an extension of WebDriver and also provides supporting software utilities to make end-to-end testing easier. Protractor includes the webdriver-manager binary, which exists to make the management of WebDriver easier.

Within the tests themselves, Protractor exports a couple of global variables for you to use, which are as follows:

The following is a checklist of things to do in order to ensure that your test suite will run correctly:

Adding Protractor to your application's test configuration requires you to follow a number of steps in order to get it installed, configured, and automated.

npm install protractor grunt-protractor-runner --save-dev

(package.json)

{
  "devDependencies": {
    // long list of node package dependencies
  },
  "scripts": {
    // additional existing script additions may be listed here
    "install": "node node_modules/protractor/bin/webdriver-manager update"
  }
}

(Gruntfile.js)

module.exports = function (grunt) {

  ...

  // Define the configuration for all the tasks
  grunt.initConfig({

    // long list of configuration options for
    // grunt tasks like minification, JS linting, etc.

    protractor: {
      options: {
        keepAlive: true,
        configFile: "protractor.conf.js"
      },
      run: {}
    }
  }

(Gruntfile.js)

grunt.registerTask('test', [
  // list of subtasks to run during `grunt test`
  'karma',
  'protractor:run'
]);

(protractor.conf.js)

exports.config = {
  specs: ['test/e2e/*_test.js'],
  baseUrl: 'http://localhost:9001',
  // your filenames, versions, and paths may differ
  seleniumServerJar: 'node_modules/protractor/selenium/selenium-server-standalone-2.42.2.jar',
  chromeDriver: 'node_modules/protractor/selenium/chromedriver'
}

Much of the power and utility that Grunt has to offer stems from its modular automation topology. The setup you just configured works roughly as follows:

For this recipe, it is assumed that you have correctly configured your local setup so that Grunt will be able to find your test file(s) and run them on the Karma test runner.

Suppose that you have the following controller within your application:

(app.js)

angular.module('myApp')
.controller('HandleCtrl', function($scope, $http) {
  $scope.handle = '';
  $scope.$watch('handle', function(value) {
      if (value.length < 6) {
          $scope.valid = false;
      } else {
          $http({
              method: 'GET',
              url: '/api/handle/' + value
          }).success(function(data, status) {
              if (status == 200 &&
                  data.handle == $scope.handle &&
                  data.id === null) {
                  $scope.valid = true;
              } else {
                  $scope.valid = false;
              }
          });
      }
  });
});

In this example application, a user named Jake Hsu will go through a signup flow and attempt to select a unique handle. In order to guarantee the selection of a unique handle while still in the signup flow, a scope watcher is set up against the server to check whether that handle already exists. Through a mechanism outside the controller (and presumably in the view), the value of $scope.handle will be manipulated, and each time its value changes, the application will send a request to the backend server and set $scope.valid based on what the server returns.

An exhaustive set of unit tests for something like the situation mentioned in the previous section can become quite lengthy. When writing tests for a production application, rarely is it prudent to spend time to create an exhaustive set of unit tests for a component, unless it is critical to the application (payments and authentication come to mind).

Here, it is probably sufficient to create a set of tests that attempts to cover scenarios that mark a handle as invalid on the client side, invalid on the server side, and valid on the server side.

(handle_controller_test.js)

// monolithic test suite for HandleCtrl
describe('Controller: HandleCtrl', function() {
  // the components to be tested reside in the myApp module
  // therefore it must be injected
  beforeEach(module('myApp'));

  // values which will be used in multiple closures
  var HandleCtrl, scope, httpBackend, createEndpointExpectation;

  // this will be run before each it(function() {}) clause
  // to create or refresh the involved components
  beforeEach(inject(function($controller, $rootScope, $httpBackend) {

    // creates the mock backend server
    httpBackend = $httpBackend;

    // creates a fresh scope
    scope = $rootScope.$new();

    // creates a new controller instance and inserts
    // the created scope into it
    HandleCtrl = $controller('HandleCtrl', {
      $scope: scope
    });

    // configures the httpBackend to match outgoing requests
    // that are expected to be generated by the controller
    // and return payloads based on what the request contained;
    // this will only be invoked when needed
    createEndpointExpectation = function() {
      // URL matching utilizes a simple regex here
      // expectGET requires that a request be created
      httpBackend.expectGET(//api/handle/w+/i).respond(
        function(method, url, data, headers){
          var urlComponents = url.split("/")
            , handle = urlComponents[urlComponents.length - 1]
            , payload = {handle: handle};

          if (handle == 'jakehsu') {
            // handle exists in database, return ID
            payload.id = 1;
          } else {
            // handle does not exist in database
            payload.id = null;
          };

          // AngularJS allows for this return format;
          // [status code, data, configuration]
          return [200, payload, {}];
        }
      );
       };
  }));

  // configures the httpBackend to check that the mock
  // server did not receive extra requests or did not
  // see a request when it should have expected one
  afterEach(function() {
    // verify that all expect<HTTPverb>() expectations were filled
    httpBackend.verifyNoOutstandingExpectation();
    // verify that the mock server did not receive requests it
    // was not expecting
    httpBackend.verifyNoOutstandingRequest();
  });

  // unit tests go here

});

(handle_controller_test.js)

// describe() serves to annotate what the module will test
describe('Controller: HandleCtrl', function() {

  // unit test initialization
  beforeEach( ... );
  afterEach( ... );

  // client invalidation unit test
  it('Should mark handles which are too short as invalid', 
    function() {
      // attempt test handle beneath the character count floor
      scope.handle = 'jake';
      // $watch will not be run until you force a digest loop
      scope.$apply();
      // this clause must be fulfilled for the test to pass
      expect(scope.valid).toBe(false);
    }
  );

  // client validation, server invalidation unit test
  it('Should mark handles which exist on the server as invalid', 
    function() {
      // server is set up to expect a specific request
      createEndpointExpectation();
      // attempt test handle above character count floor,
      // but which is defined in the mock server to have already
      // been taken
      scope.handle = 'jakehsu';
      // force a digest loop
      scope.$apply();
      // the mock server will not return a response until 
      // flush() is invoked
      httpBackend.flush();
      // this clause must be fulfilled for the test to pass
      expect(scope.valid).toBe(false);
    }
  );

  // client validation, server invalidation unit test
  it('Should mark handles available on the server as valid', 
    function() {
      // server is set up to expect a specific request
      createEndpointExpectation();
      // attempt handle above character floor and
      // which is defined to be available on the mock server
      scope.handle = 'jakehsu123';
      // force a digest loop
      scope.$apply();
      // return a response
      httpBackend.flush();
      // this clause must be fulfilled for the test to pass
      expect(scope.valid).toBe(true);
    }
 );

Each unit test describes the sequential components that describe a scenario that the application is supposed to handle. Though the JavaScript that is natively executed in the browser is heavily asynchronous, the unit test faculties provide a great deal of control over these operations such that you can control the completion of asynchronous operations, and therefore test your application's handling of it in different ways. The $http and $digest cycles are both components of AngularJS that are expected to take indeterminate amounts of time to complete. Here though, you are given fine-grained control over their execution, and it is to your advantage to incorporate that ability into the test suite for more extensive test coverage.

Unit tests should be the core of your test suite as they provide the best assurance that the components of your application are behaving as expected. The rule of thumb is: if it's possible to effectively test a component with a unit test, then you should use a unit test.

This recipe will use the same application controller setup from the preceding recipe, Writing basic unit tests. Please refer to the setup instructions and code explained there.

In order to provide an interface to utilize the controller, the application will also incorporate the following:

(app.js)

angular.module('myApp', [
  'ngRoute'
])
  .config([
    '$routeProvider',
    function($routeProvider){
      $routeProvider
        .when('/signup', {
          templateUrl: 'views/main.html'
        })
        .otherwise({
          redirectTo: '/',
          template: '<a href="/#/signup">Go to signup page</a>'
        });
    }
  ]);

(views/main.html)

<div ng-controller="HandleCtrl">
  <input type="text" ng-model="handle" />
  <h2 id="success-msg" ng-show="valid">
    That handle is available!
  </h2>
  <h2 id="failure-msg" ng-hide="valid">
    Sorry, that handle cannot be used.
  </h2>
</div>

(index.html)
<body ng-app="myApp">
  <div ng-view=""></div>
</body>

Your end-to-end test suite should cover all user flows as best as you can. Ideally, you will optimize for a balance between modularity, independence, and redundancy avoidance when you write tests. For example, each individual test probably doesn't need you to log out at the end of the test since this would only serve to slow down the completion of the tests. However, if you are writing E2E tests to verify that your application's authentication scheme prevents unwanted navigation after authentication credentials have been revoked. Then, an array of tests that test actions after logout would be very appropriate. The focus of your tests will vary depending on the style and purpose of your application, and also the bulk and complexity of the codebase behind it.

Since the protractor.conf.js file has been instructed to look for test files in the test/e2e/ directory, the following would be an appropriate test suite in that location:

(test/e2e/signup_flow_test.js)

describe('signup flow tests', function() {

  it('should link to /signup if not already there', function() {
    // direct browser to relative url, 
    // page will load synchronously
    browser.get('/');

    // locate and grab <a> from page
    var link = element(by.css('a'));

    // check that the correct <a> is selected 
    // by matching contained text
    expect(link.getText()).toEqual('Go to signup page');

    // direct browser to nonsense url
    browser.get('/#/hooplah');

    // simulated click
    link.click();

    // protractor waits for the page to render, 
    // then checks the url
    expect(browser.getCurrentUrl()).toMatch('/signup');
  });
});

describe('routing tests', function() {

  var handleInput,
      successMessage,
      failureMessage;

  function verifyInvalid() {
    expect(successMessage.isDisplayed()).toBe(false);
    expect(failureMessage.isDisplayed()).toBe(true);
  }

  function verifyValid() {
    expect(successMessage.isDisplayed()).toBe(true);
    expect(failureMessage.isDisplayed()).toBe(false);
  }

  beforeEach(function() {
    browser.get('/#/signup');

    var messages = element.all(by.css('h2'));

    expect(messages.count()).toEqual(2);

    successMessage = messages.get(0);
    failureMessage = messages.get(1);

    handleInput = element(by.model('handle'));

    expect(handleInput.getText()).toEqual('');

  })

  it('should display invalid handle on pageload', function() {

    verifyInvalid();

    expect(failureMessage.getText()).
      toEqual('Sorry, that handle cannot be used.');
  });

  it('should display invalid handle for insufficient characters', function() {

    // type to modify model and trigger $watch expression
    handleInput.sendKeys('jake');

    verifyInvalid();
  })

  it('should display invalid handle for a taken handle', function() {

    // type to modify model and trigger $watch expression
    handleInput.sendKeys('jakehsu');

    verifyInvalid();
  })

  it('should display valid handle for an untaken handle', function() {

    // type to modify model and trigger $watch expression
    handleInput.sendKeys('jakehsu123');

    verifyValid();
  })
});

Protractor utilizes a Selenium server and WebDriver to fully render your application in the browser and to simulate a user interacting with it. The end-to-end test suite provides faculties for you to simulate native browser events in the context of an actual running instance of your application. The end-to-end tests verify correctness not by the JavaScript object state of the application, but rather by inspecting the state of either the browser or the DOM.

Since end-to-end tests are interacting with an actual browser instance, they must be able to manage asynchronicity and uncertainty during execution. To do this, each of the element selectors and assertions in these end-to-end tests return promises. Protractor automatically waits for each promise to get completed before continuing to the next test statement.

AngularJS provides the ngMockE2E module, which allows you to mock a backend server. Incorporating the module gives you the ability to prevent the application from making actual requests to a server, and instead simulates request handling in a fashion similar to that of the unit tests. However, incorporating this module into your application is actually not recommended in many cases, for the following reasons:

Therefore, it is encouraged to structure your end-to-end tests in order to send requests to a legitimate backend in order to effectively and more realistically simulate client-server HTTP conversations.

Selecting a mock server style has essentially no limitations as the only requirement is for it to allow you to manually configure responses upon expected HTTP requests. As you might imagine, this can get as simple or as complex as you want, but the nature of end-to-end testing tends to lead to frequent overhaul and repair of large pieces of the mock HTTP endpoints if they try and replicate large amounts of the production application logic.

If you are able to (and in most cases, you absolutely should be able to design or refactor your tests in such a way) have your end-to-end tests perform more concise application user flows and mock out the API that it communicates with as simply as possible, you should do it—usually, this mostly means hardcoding the responses. Enter the file-based API server!

(httpMockBackend.js)

// Define some initial variables.
var applicationRoot = __dirname.replace(/\/g,'/')
  , ipaddress = process.env.OPENSHIFT_NODEJS_IP || '127.0.0.1'
  , port = process.env.OPENSHIFT_NODEJS_PORT || 5001
  , mockRoot = applicationRoot + '/test/mocks/api'
  , mockFilePattern = '.json'
  , mockRootPattern = mockRoot + '/**/*' + mockFilePattern
  , apiRoot = '/api'
  , fs = require("fs")
  , glob = require("glob");

// Create Express application
var express = require('express');
var app = express();

// Read the directory tree according to the pattern specified above.
var files = glob.sync(mockRootPattern);

// Register mappings for each file found in the directory tree.
if(files && files.length > 0) {
  files.forEach(function(filePath) {

    var mapping = apiRoot + filePath.replace(mockRoot, '').replace(mockFilePattern,'')
      , fileName = filePath.replace(/^.*[\/]/, '');

    // set CORS headers so this can be used with local AJAX
    app.all('*', function(req, res, next) {
      res.header("Access-Control-Allow-Origin", "*");
      res.header(
        'Access-Control-Allow-Headers', 
        'X-Requested-With'
      );
      next();
    });

    // any HTTP verbs you might need
    [/^GET/, /^POST/, /^PUT/, /^PATCH/, /^DELETE/].forEach(
      function(httpVerbRegex) {

        // perform the initial regex of the HTTP verb 
        // against the filename
        var match = fileName.match(httpVerbRegex);

        if (match != null) {
          // remove the HTTP verb prefix from the filename
          mapping = mapping.replace(match[0] + '_', '');

          // create the endpoint
          app[match[0].toLowerCase()](mapping, function(req,res) {

            // handle the request by responding 
            // with the JSON contents of the file
            var data =  fs.readFileSync(filePath, 'utf8');
            res.writeHead(200, { 
              'Content-Type': 'application/json' 
            });
            res.write(data);
            res.end();
          });
        }
      }
    );

    console.log('Registered mapping: %s -> %s', mapping, filePath);
  });
} else {
  console.log('No mappings found! Please check the configuration.');
}

// Start the API mock server.
console.log('Application root directory: [' + applicationRoot +']');
console.log('Mock Api Server listening: [http://' + ipaddress + ':' + port + ']');
app.listen(port, ipaddress);

This is a simple node program that can be run using the following command:

$ node httpMockServer.js

This simple express.js server conveniently matches the incoming request URLs to the corresponding JSON file in the test/mocks/api/ child directory, and it matches the HTTP verb of the request to the file prefixed with that verb. So, a GET request to localhost:5001/api/user will return the JSON contents of /test/mocks/api/GET_user.json, a PATCH request to localhost:5001/api/user/1 will return the JSON contents of /test/mocks/api/user/PATCH_1.json, and so on. Since files are automatically discovered and added to the express routing, this allows you to easily simulate a backend server with very different request types, quickly.

This setup is obviously extremely limited in a number of ways, including conditional request handling and authentication, to name a few. This is not intended as a full replacement for a backend by any means, but if you are trying to quickly build a test suite or build a piece of your application that sits atop an HTTP API, you will find this tool very useful.

The following tests are a sample of unit tests from the Writing basic unit tests recipe, presented here unchanged:

  it('should display invalid handle for insufficient characters', function() {

    // type to modify model and trigger $watch expression
    handleInput.sendKeys('jake');

    verifyInvalid();
  })

  it('should display invalid handle for a taken handle', function() {

    // type to modify model and trigger $watch expression
    handleInput.sendKeys('jakehsu');

    verifyInvalid();
  })

As is, this would be considered a set of DAMP tests. A developer running these tests would have little trouble quickly piecing together what is supposed to happen, where in the code it's happening, and why the tests might be failing.

However, a DRY-minded developer would examine these tests, identify the redundancy between them, and refactor them into something like the following:

  it('should reject invalid handles', function() {
    // type to modify model and trigger $watch expression
    ['jake', 'jakehsu'].forEach(function(handle){
      handleInput.clear();
      handleInput.sendKeys(handle);
      verifyInvalid();
    });
  });

This code is definitely more in line with the DRY principle than the previous one, and the tests will still pass and still test the proper behavior, but there is already a measurable loss of information that hurts the quality of the tests. The initial version of the unit tests presented two test cases that were both supposed to be marked as invalid, but for different reasons—one because of a minimum handle length, one because the request to the mock server reveals that the handle is already taken. If one of those tests were to fail, the developer running them would be directed to the exact test case that was failing, would have good insight into which aspect of the validation was failing, and would be able to quickly act accordingly. In the DRY version of the unit tests, the developer running them would see a failed test, but since the two unit tests were condensed, it isn't immediately obvious which one of them is causing the failure or why it is failing. In this scenario, the DAMP tests are more conducive to rapidly locate and repair bugs that might crop up in the application.

The example in this recipe is a relatively simple one, but it demonstrates the fundamental difference between the DAMP and DRY practices. In general, the rule of thumb is for production code to be as DRY as possible, and for test suites to be as DAMP as possible. Production code should be optimized for maintainability, and tests for understandability.

Perhaps counterintuitively, the DAMP principle is not necessarily mutually exclusive with the DRY principle—they are merely suited for different purposes. Unit and end-to-end tests should be DRYed wherever it will make the code more maintainable as long as it doesn't hurt the readability of the tests. Generally, this will fall under the setup and teardown routines for tests—use the DRY principle for these routines as much as possible, since they infrequently contain information or procedures that are relevant to the application component(s) that the test is covering. Authentication and navigation are both good examples of test setup/teardown that respond well to DRY refactoring.

The test/e2e/signup_flow_test.js file presented in the Writing basic E2E tests recipe can be refactored into the following files using the Page Object pattern.

The test/pages/main.js file can be refactored as follows:

(test/pages/main.js)

var MainPage = function () {
  // direct the browser when the page object is initialized
  browser.get('/');
};

MainPage.prototype = Object.create({},
  {
    // getter for element in page
    signupLink: {
      get: function() {
        return element(by.css('a'));
      }
    }
  }
);

module.exports = MainPage;

The test/pages/signup.js file can be refactored as follows:

(test/pages/signup.js)

var SignupPage = function () {
  // direct the browser when the page object is initialized
  browser.get('/#/signup');
};

SignupPage.prototype = Object.create({},
  {
    // getters for elements in the page
    messages: {
      get: function() {
        return element.all(by.css('h2'));
      }
    },
    successMessage: {
      get: function() {
        return this.messages.get(0);
      }
    },
    failureMessage: {
      get: function() {
        return this.messages.get(1);
      }
    },
    handleInput: {
      get: function() {
        return element(by.model('handle'));
      }
    },
    // getters for page validation
    successMessageVisibility: {
      get: function() {
        return this.successMessage.isDisplayed();
      }
    },
    failureMessageVisibility: {
      get: function() {
        return this.failureMessage.isDisplayed();
      }
    },
    // interface for page element
    typeHandle: {
      value: function(handle) {
        this.handleInput.sendKeys(handle);
      }
    }
  }
);

module.exports = SignupPage;

The test/e2e/signup_flow_test.js file can be refactored as follows:

(test/e2e/signup_flow_test.js)

var SignupPage = require('../pages/signup.js')
  , MainPage = require('../pages/main.js');

describe('signup flow tests', function() {

  var page;

  beforeEach(function() {
    // initialize the page object
    page = new MainPage();
  });

  it('should link to /signup if not already there', function() {

    // check that the correct <a> is selected 
    // by matching contained text
    // expect(link.getText()).toEqual('Go to signup page');
    expect(page.signupLink.getText()).toEqual('Go to signup page');

    // direct browser to nonsense url
    browser.get('/#/hooplah');

    // simulated click
    page.signupLink.click();

    // protractor waits for the page to render, 
    // then checks the url
    expect(browser.getCurrentUrl()).toMatch('/signup');
  });
});

describe('routing tests', function() {

  var page;

  function verifyInvalid() {
    expect(page.successMessageVisibility).toBe(false);
    expect(page.failureMessageVisibility).toBe(true);
  }

  function verifyValid() {
    expect(page.successMessageVisibility).toBe(true);
    expect(page.failureMessageVisibility).toBe(false);
  }

  beforeEach(function() {

    // initialize the page object
    page = new SignupPage();

    // check that there are two messages on the page
    expect(page.messages.count()).toEqual(2);

    // check that the handle input text is empty
    expect(page.handleInput.getText()).toEqual('');

  });

  it('should display invalid handle on pageload', function() {

    // check that initial page state is invalid
    verifyInvalid();

    expect(page.failureMessage.getText()).
      toEqual('Sorry, that handle cannot be used.');
  });

  it('should display invalid handle for insufficient characters', function() {

    // type to modify model and trigger $watch expression
    page.typeHandle('jake');

    verifyInvalid();
  })

  it('should display invalid handle for a taken handle', function() {

    // type to modify model and trigger $watch expression
    page.typeHandle('jakehsu');

    verifyInvalid();
  })

  it('should display valid handle for an untaken handle', function() {

    // type to modify model and trigger $watch expression
    page.typeHandle('jakehsu123');

    verifyValid();
  })
})

It should be immediately obvious as to why this test pattern is desirable. Looking through the actual tests, you now do not need to know any information about the specifics of the page contents to understand how the test is manipulating the application.

The page objects take advantage of the second and optional objectProperties argument of Object.create() to build a very pleasant interface to the page. By using these page objects, you are able to avoid all of the nastiness of creating a sea of local variables to store references to the pieces of the page. They also offer a great deal of flexibility in terms of where the bulk of your test logic lies. These tests could potentially be refactored even more to move the validation logic into the page objects. Decisions like these are ultimately up to the developer, and it boils down to their preference in terms of how dense the page objects should be.

In this example, the page object getter interface is especially useful since the nature of end-to-end tests implies that you will need to evaluate the page state at several checkpoints in the lifetime of the test, and a defined getter that performs this evaluation while appearing as a page object property yields an extremely clean test syntax.

Also note the multiple layers of indirection within the SignupPage object. Layering in this fashion is absolutely to your advantage, and the page object is a prime place in your end-to-end tests where it really does pay to be DRY. Repetitious location of elements on the page is not the place for verbosity!