Part 1: Terminology and Reasons to use Page Objects
Using Page Objects with Behavior Driven Development in an Agile Environment Demonstration
Page Objects – The best way to think of Page Objects is to think of them as representing the services offered by a particular page. The simplest way to understand Page Objects is to think of the methods on a Page Object as offering the “services” that a page offers rather than exposing the details and mechanics of the page. This reduces the amount of duplicated code and means that if the UI changes, the fix need only be applied in one place.
Test Driven Development (TDD) – is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
Behavior Driven Development (BDD) – is a specialized version of test-driven development which focuses on behavioral specification of software units. Behavior Driven Development is thought of as an “outside-in” approach to building software, the initial phase consists of “modeling” the desired behaviors of the feature and then building the tests and code from the behavior models. During the sprint design session the team will mockup the feature to be added or changed.
Reason for using Page Objects with Behavior Driven Development in an Agile Environment
Allows Functional Tests to be written at the start of the Sprint – An Agile team using BDD creates the behavior models at the start of a new sprint during a design session, since Page Object methods represent the services available on the models we can stub out our Page Objects along with the corresponding test cases without needing to see the underlying code. By doing this we now can start creating our automated functional tests in a TDD type of fashion. Much like Test Driven Development, the automation developers create initial Page Objects and test cases and refactor them as they receive pieces of code during the sprint.
Allows for true Agile development – Many Organizations attempting to use the Agile methodology follow one of two paths today, they either use TDD and have their developers create Unit tests for their automation or they use a system such as having a two week sprint where they code the new application feature or change some legacy feature and then have a follow on two week sprint where they automate the code from the previous sprint. The main reason for having to use the one of the two paths above is because they are dependent on using an automation tool that was not designed to be used in an agile environment. If your automation tool is either a record and play tool or a tool that is dependent on code being delivered first then it is advisable to investigate automation tools that allow for the Page Object methodology.
Quality Assurance can participate in automation – When an Agile team uses the BDD methodology, the possibility of using your existing Quality Assurance team to do Functional automation during the code development sprint is now possible. Just like a developer creating Unit tests in the TDD methodology, the Quality Assurance team can now create Functional automated tests in a TDD fashion due to the fact that the BDD methodology calls for creating models initially that allows for Page Objects and test cases to be stubbed out and refactored as code is delivered.