Credit: Alicia Kubista / Andrij Borys Associates
End-to-end testing of Web applications typically involves tricky interactions with Web pages by means of a framework such as Selenium WebDriver.12 The recommended method for hiding such Web-page intricacies is to use page objects,10 but there are questions to answer first: Which page objects should you create when testing Web applications? What actions should you include in a page object? Which test scenarios should you specify, given your page objects?
While working with page objects during the past few months to test an AngularJS (https://angularjs.org) Web application, I answered these questions by moving page objects to the state level. Viewing the Web application as a state chart made it much easier to design test scenarios and corresponding page objects. This article describes the approach that gradually emerged: essentially a state-based generalization of page objects, referred to here as state objects.
Very neat use of state machines and diagrams; it's great to see someone modeling the ideas before jumping straight into code. It's a pleasant surprise that there's so few lines of end2end testing code:
> The application's end-to-end test suite uses state objects. It consists of about 25 state objects and 75 scenarios. Like the PhoneCat test suite, it uses Protractor and consists of about 1,750 lines of JavaScript.
In a production environment covering even a few scenarios can reduce regressions and the amount of bugs.
Displaying 1 comment