DSL, Page Object and WebDriver –
the path to reliable functional tests
          Mikalai Alimenkou
        http://xpinjection.com
              06.10.2011
Background
• Java Technical Lead/Scrum Master at
  Zoral Labs
• 7+ years in software development
• 5+ years of working by Agile
  methodologies
• Expert in Agile engineering practices
• Agile coach (TDD, Testing, Planning, etc.)
  at XP Injection (http://xpinjection.com)
• Organizer of Selenium Camp, JEEConf and
  XP Days Ukraine conferences
Agenda
•   WebDriver tests issues
•   Step 1: DSL introduction
•   Step 2: Page Object pattern
•   Step 3: Page Element pattern
•   Results analysis
When you have a hammer, everything looks like a nail

WEBDRIVER TESTS ISSUES
Test Components

Application                 Test
  Driver                    Data




                     Test
                    Logic
How WebDriver Works?
                     Get Driver




   Invoke Commands

                           Provide Data




                          Use Locators
Selenium Tests Issues: Verbose
 By.xpath(“//input*@value=‘continue’+”)

                                          driver.findElement(By.xpath(…)).sendKeys(…);

driver.findElement(By.name(…)).click();
                                By.css(“#results dip p.first”)
    By.id(“greenButton”)
                           driver.findElements(…).size();

 new WebDriverWait(driver, 30).until(…);
Selenium Tests Issues: Not Expressive
Selenium Tests Issues: Unreadable
Selenium Tests Issues: Fragile
driver.findElement(By.xpath("//input[@id=(//label[tex
t()='Fax']/@for)]")).click();

                                    What is going on here?



driver.findElement(By.xpath("//div[@id='App']/div/p[4]/di
v[1]/h4[@class='Online']")).getText()

          Depends too much on
            page structure!
Even More Hidden Issues
                  Test code
                 duplication
      Hard to
    understand                 No reuse



Fewer tests                        Hard to
  created                          support



     Hard to                   Test wrong
   create new                    things

                 Performance
                  problems
What is the Primary Goal?
 To enable reliable stable tests we need to
  separate all parts as much as possible
                          Reliability


                          Clarity
Test             Test
Data            Logic
                          Flexibility

  Application
                          Maintainability
       Driver
                          Stability
Ideal Testing Framework

       Test Logic            Test Data
                              Storage


 DSL Application Driver



    Technical Driver         Technical
                            Data Storage


Application Under Testing
Create domain-specific language for your application

STEP 1: INTRODUCE DSL
Definition of DSL

    A domain-specific language (DSL) is a
   programming language or specification
language dedicated to a particular problem
domain, that is created specifically to solve
  problems in this particular domain and is
 not intended to be able to solve problems
outside it (although that may be technically
                  possible).
DSL Usage Sample
DEMO
Benefits of DSL Approach
• High-level – tests are in the language of
  product management, at the user level
• Readable – product management can
  understand them
• Writable – easy for developer or QA to write
  new test
• Extensible – tests base is able to grow with
  DSL
Tips and Tricks
• Use test class hierarchy or test helpers
• Use builders, visitors and other design
  patterns
• Reuse domain model from application
• Some common methods move to base test
  class
• Minimize usage of driver instance in tests
Create page map for your application

STEP 2: INTRODUCE PAGE OBJECT
Page Object Pattern
              search                     order
Index
 Page

                              Search
                               Page
login
            search
                                       filter
Main
Page                   open


                                   see more
               Details
  close         Page
                                                 show me like this
Test Architecture with Page Object
Components Architecture
Isolated                     Concepts
  logic                     separation




  Easier
 support                     Simplicity
Ways to Implement Page Object
                      Duplicate Site Map
                      with Packages and
                            Classes




Move Site Structure
  to UI-Element
WebDriver Page Object Support
DEMO
“Ideal” Page Object in WebDriver
Tips and Tricks
• Allow chain invocations
• Basic page with driver details and common
  methods
• Use already included Page Object classes to
  simplify pages creation
• Expose only what is allowed to see or do on the
  page
• Don’t use driver instance in tests at all
• Use static analysis to check rules
• Use site map to prepare Page Objects
Divide pages on reusable elements

STEP 3: PAGE ELEMENTS
Page Consists of Elements
                                 Menu




                    Checkbox            Panel

Link




List of Items
Different Page Elements
     Checkbox                 TextBox                Button

•   click               •   type              •   click
•   isChecked           •   hasValue          •   doubleClick
•   check               •   focus             •   clickAndWait
•   uncheck             •   clearText         •   …
•   …                   •   typeAndReturn
                        •   isEditable
                        •   …




Table           Items        Menu           Panel       Form
Why Page Element Pattern?

       Highest
                  Clear page
       level of
                   structure
     code reuse




      Building
                   Reliable
     pages from
                    tests
    components
Inversion of Control

Hides the details of
browser communication                After

     Before



                           Expose methods for what
                                test can see and do
DEMO
Tellurium Project
Tellurium Basics: UI Module
              Groovy File
                                  Can Build XPath in
                                      Runtime


   All
Elements
           Element UID                  Isolated
                                        Locators

                            Available
                             Actions
Tellurium Basics: UI Object
• uid – unique in UI module
• namespace – for future extension
• locator – locator of the UI object
  – A base locator (relative XPath)
  – A composite locator (object attributes)
• group – applied to some kinds of UI objects to
  switch on grouping locating
• respond – define JavaScript events the UI object
  could respond to
• some basic methods – isElementPresent,
  isVisible, isDisabled, waitForElementPresent,
  getText, mouseOver, mouseOut, getAttribute
Tellurium IDE and TrUMP
DEMO
Tips and Tricks
•   Create elements when first need them
•   Review and improve elements continuously
•   Isolate and hide hacks inside elements
•   Use open source libraries as basis
•   Use annotations and other metadata
    techniques to simplify creation
What we have at the end of long way?

RESULTS ANALYSIS
Long Path Bring Us to…
•   Reliable tests
•   Reusable test code
•   Separation of concepts
•   Expressive tested UI structure
•   Short and clear tests
•   Tests look more like acceptance tests
•   Tests are understood by non-technical people
Company DSL Library
Components may be reused between different
 applications and projects inside a company

   Company                          AJAX
    Portal                       Components



  Online Store                      Basic
                                 Components

   Customer
    Service                         JSF
                                 Components
@xpinjection
             http://xpinjection.com
mikalai.alimenkou@xpinjection.com

DSL, Page Object and WebDriver – the path to reliable functional tests.pptx

  • 1.
    DSL, Page Objectand WebDriver – the path to reliable functional tests Mikalai Alimenkou http://xpinjection.com 06.10.2011
  • 2.
    Background • Java TechnicalLead/Scrum Master at Zoral Labs • 7+ years in software development • 5+ years of working by Agile methodologies • Expert in Agile engineering practices • Agile coach (TDD, Testing, Planning, etc.) at XP Injection (http://xpinjection.com) • Organizer of Selenium Camp, JEEConf and XP Days Ukraine conferences
  • 3.
    Agenda • WebDriver tests issues • Step 1: DSL introduction • Step 2: Page Object pattern • Step 3: Page Element pattern • Results analysis
  • 4.
    When you havea hammer, everything looks like a nail WEBDRIVER TESTS ISSUES
  • 5.
    Test Components Application Test Driver Data Test Logic
  • 6.
    How WebDriver Works? Get Driver Invoke Commands Provide Data Use Locators
  • 7.
    Selenium Tests Issues:Verbose By.xpath(“//input*@value=‘continue’+”) driver.findElement(By.xpath(…)).sendKeys(…); driver.findElement(By.name(…)).click(); By.css(“#results dip p.first”) By.id(“greenButton”) driver.findElements(…).size(); new WebDriverWait(driver, 30).until(…);
  • 8.
    Selenium Tests Issues:Not Expressive
  • 9.
  • 10.
    Selenium Tests Issues:Fragile driver.findElement(By.xpath("//input[@id=(//label[tex t()='Fax']/@for)]")).click(); What is going on here? driver.findElement(By.xpath("//div[@id='App']/div/p[4]/di v[1]/h4[@class='Online']")).getText() Depends too much on page structure!
  • 11.
    Even More HiddenIssues Test code duplication Hard to understand No reuse Fewer tests Hard to created support Hard to Test wrong create new things Performance problems
  • 12.
    What is thePrimary Goal? To enable reliable stable tests we need to separate all parts as much as possible Reliability Clarity Test Test Data Logic Flexibility Application Maintainability Driver Stability
  • 13.
    Ideal Testing Framework Test Logic Test Data Storage DSL Application Driver Technical Driver Technical Data Storage Application Under Testing
  • 14.
    Create domain-specific languagefor your application STEP 1: INTRODUCE DSL
  • 15.
    Definition of DSL A domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, that is created specifically to solve problems in this particular domain and is not intended to be able to solve problems outside it (although that may be technically possible).
  • 16.
  • 17.
  • 18.
    Benefits of DSLApproach • High-level – tests are in the language of product management, at the user level • Readable – product management can understand them • Writable – easy for developer or QA to write new test • Extensible – tests base is able to grow with DSL
  • 19.
    Tips and Tricks •Use test class hierarchy or test helpers • Use builders, visitors and other design patterns • Reuse domain model from application • Some common methods move to base test class • Minimize usage of driver instance in tests
  • 20.
    Create page mapfor your application STEP 2: INTRODUCE PAGE OBJECT
  • 21.
    Page Object Pattern search order Index Page Search Page login search filter Main Page open see more Details close Page show me like this
  • 22.
  • 23.
    Components Architecture Isolated Concepts logic separation Easier support Simplicity
  • 24.
    Ways to ImplementPage Object Duplicate Site Map with Packages and Classes Move Site Structure to UI-Element
  • 25.
  • 26.
  • 27.
  • 28.
    Tips and Tricks •Allow chain invocations • Basic page with driver details and common methods • Use already included Page Object classes to simplify pages creation • Expose only what is allowed to see or do on the page • Don’t use driver instance in tests at all • Use static analysis to check rules • Use site map to prepare Page Objects
  • 29.
    Divide pages onreusable elements STEP 3: PAGE ELEMENTS
  • 30.
    Page Consists ofElements Menu Checkbox Panel Link List of Items
  • 31.
    Different Page Elements Checkbox TextBox Button • click • type • click • isChecked • hasValue • doubleClick • check • focus • clickAndWait • uncheck • clearText • … • … • typeAndReturn • isEditable • … Table Items Menu Panel Form
  • 32.
    Why Page ElementPattern? Highest Clear page level of structure code reuse Building Reliable pages from tests components
  • 33.
    Inversion of Control Hidesthe details of browser communication After Before Expose methods for what test can see and do
  • 34.
  • 35.
  • 36.
    Tellurium Basics: UIModule Groovy File Can Build XPath in Runtime All Elements Element UID Isolated Locators Available Actions
  • 37.
    Tellurium Basics: UIObject • uid – unique in UI module • namespace – for future extension • locator – locator of the UI object – A base locator (relative XPath) – A composite locator (object attributes) • group – applied to some kinds of UI objects to switch on grouping locating • respond – define JavaScript events the UI object could respond to • some basic methods – isElementPresent, isVisible, isDisabled, waitForElementPresent, getText, mouseOver, mouseOut, getAttribute
  • 38.
  • 39.
  • 40.
    Tips and Tricks • Create elements when first need them • Review and improve elements continuously • Isolate and hide hacks inside elements • Use open source libraries as basis • Use annotations and other metadata techniques to simplify creation
  • 41.
    What we haveat the end of long way? RESULTS ANALYSIS
  • 42.
    Long Path BringUs to… • Reliable tests • Reusable test code • Separation of concepts • Expressive tested UI structure • Short and clear tests • Tests look more like acceptance tests • Tests are understood by non-technical people
  • 43.
    Company DSL Library Componentsmay be reused between different applications and projects inside a company Company AJAX Portal Components Online Store Basic Components Customer Service JSF Components
  • 44.
    @xpinjection http://xpinjection.com [email protected]