Today’s automation tests should possess readability characteristics, consisting of fluidness, clarity and flexibility. In spite of the fact that the majority of the examples litter the internet promoting page-object design with: fragment statements, choppy commands and multiple line assertion blocks; yet, rarely address readability as a first class citizen.
 
Despite the enormous power page-objects furnish, the design alone does not provide all the required mechanisms  to construct high-level readable tests with the attributes as described above. To achieve this new level of readability required a new approach and a new design. A design that is flexible, with a straightforward implementation, and one that already works with existing page-objects.
 
The HPA design (Handlers-Page Objects-Assertions) provides the fluidness for tests to move from page-object to page-object, while displaying visual clues where the reader is within the application. In addition, it exposes assertion methods within the test to determine the "expectation of correctness”. Integrating the Handler and Assertions classes with the Page-Object design, test readability simply explodes — with clean, readable assertions, rich details and elimination of boiler-plate code. 
 
Note
Currently, HPA has been implemented in Java across numerous applications from typical multiple page application to SPAs (Single Page Application), in addition, the design should be easily applicable to C#, and could be applied to the scripting languages as well.
 
 
 
2 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

1. Welcome & Introduction
2. Analyze a Traditional Test Case with Several Page Objects
3. Introduction of Handlers
        Develop a Handler Class for each Page Object
4. Introduction of Assertions
        Develop an Assertion Class for each Page Object
5. Wire Up the Parts: Handler, Page Object & Assertion
        Develop the  “glue code” 
        Update the Test Case
6. Summary
7. Questions

Learning Outcome

At the end of the session, participants will understand the basic structure of the HPA design, while able to implement high-level readable tests and
how to retrofit existing page objects; furthermore, when to implement only the relevant features from the design.

Target Audience

Developers currently using the page object design

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Anand Bagmar
    By Anand Bagmar  ~  2 years ago
    reply Reply

    Are you saying assertions will be available at the page-object layer?

    • Shawn Knight
      By Shawn Knight  ~  2 years ago
      reply Reply

      I am not, though, you could, and I have in past projects. However, with experience, I found exposing the assertion classes at the test layer a better approach, primarily when working with a high number of page-objects from a single page or with SPAs.

      • Anand Bagmar
        By Anand Bagmar  ~  2 years ago
        reply Reply

        Thank you! I agree page level objects should not have assertions in them. Is there any sample code you could share to understand this better? 

        • Shawn Knight
          By Shawn Knight  ~  2 years ago
          reply Reply

          I do have a blog post and github project around this design; however, it would expose my identity -- Below is a small sample and please excuse the formatting, I doubt it will display correctly.

           

          ---- Example Test ----

          @Test

             public void test()

             {

                 home()

                       .navigateToStatusCodesDashboard()

                 .statusCodesDashboard()

                         .navigateToStatus500()

                 .status500();

                 assertions().status500Assertions().verify500StatusCodeIsDisplayed();

             }

           

          ---- Example Handler Class ----

           

          public class HomeHandlerImpl implements HomeHandler

          {

             private Home home;

              @Override

              public Home home()

              {

                  return home.get();

              }

              public HomeHandlerImpl(WebDriver driver)

              {

                  home = new HomePO(driver);

              }

          }

           

          ---- Example Page Object Class -----

           

          public class Status200PO extends PageObject implements Status200

          {

              private By hereLink = By.cssSelector("a[href *= 'status_codes']");

              private By statusCodeText = By.cssSelector(".example p");

           

              @Override

              public StatusCodesDashboardHandler navigateToStatusCodesDashboard()

              {

                  getDriver().findElement(hereLink).click();

                  return getHandlers().statusCodesDashboardHandler();

              }

           

              @Override

              public String readStatusCodeText()

              {

                  return getDriver().findElement(statusCodeText).getText();

              }

           

              public Status200PO(WebDriver driver)

              {

                  super(driver);

              }

           

              @Override

              public boolean isLoaded()

              {

                  return isLoaded(Arrays.asList(hereLink));

              }

          }


  • Liked Jonathan Lipps
    keyboard_arrow_down

    Jonathan Lipps - The Mobile JSON Wire Protocol

    45 mins
    Talk
    Intermediate

    The JSON Wire Protocol (JSONWP) is the version of the WebDriver spec currently implemented by all the Selenium clients. It defines an HTTP API that models the basic objects of web automation---sessions, elements, etc... The JSON Wire Protocol is the magic that powers Selenium's client/server architecture, enables services like Selenium Grid or Sauce Labs to work, and gives you the ability to write your test scripts in any language.

    The JSONWP has served Selenium faithfully for a number of years, but the future of automated testing lies beyond the borders of the web browser. Mobile automation is an essential ingredient in any build, and tools like Appium or Selendroid have made it possible to run tests against mobile apps using the JSONWP. The JSONWP's current incarnation isn't enough to automate all the new behaviors that mobile apps support, however. Complex gestures, multiple device orientations, airplane mode, and the ability to use both native and web contexts, for example, are all essential to mobile automation.

    For this reason the leaders of the Selenium project, in concert with other Selenium-based projects like Appium and Selendroid, met to discuss the future of the JSONWP. We've been working on its next version, called the "Mobile JSON Wire Protocol" (MJSONWP). Appium and Selendroid already implement much of the MJSONWP spec. In this talk I'll dive into the specifics of the MJSONWP extensions, how they relate to the original JSONWP, and how the Selenium clients have begun to implement them.

    Finally, I will talk about the future of the MJSONWP and how it's related to the current and future versions of the WebDriver spec. I'll share how you can get help with the creation of the MJSONWP, and discuss issues with the authors of the new spec before the API is set in stone. We need the help of everyone who's involved in mobile automation to come up with the best and most future-proof version of the MJSONWP. Ultimately, your understanding of how Selenium works will be improved, and you'll have a much better handle on how projects like Appium and Selenium work together to make sure you have the best automation methods available.

  • Liked Ragavan Ambighananthan
    keyboard_arrow_down

    Ragavan Ambighananthan - Distributed Automation Using Selenium Grid / AWS / Autoscaling

    45 mins
    Talk
    Advanced

    Speed of UI automation has always been an issue when it comes to Continuous Integration / Continuous Delivery. If UI automation suite takes 3 hours to complete, then any commit happens during this time will not be visible in test environment, because the next deployment will happen only after 3 hours. 

    With 2000+ developers and average 250+ checkins per day, the above issues is replicated 250+ times every day. This is not productive and feedback cycle is super slow!

    Another issue is , with 35+ different project teams using 10 or more different jenkins jobs to run their UI automation. So many jobs means (350+), individual teams need to go through the pain of managing their own jenkins job, its a duplicate effort and waste of time. Automation teams need to spend time on writing reliable automation and not managing jenkins jobs.

    Solution is to reduce the UI automation run time from hours to minutes and also use only handful of jobs to run the Distributed Automation!

    Goal: To run all UI automation scenarios within the time take by the longest test case

  • Liked Russell Rutledge
    keyboard_arrow_down

    Russell Rutledge - Blazing Fast UI Validation - 5000 Reliable Tests in 10 Minutes on One Machine

    Russell Rutledge
    Russell Rutledge
    Senior Technical Lead
    Nike
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Advanced

    A big blocker for putting a website on truly continuous production delivery is the amount of time it take to validate that the site works correctly.  Tests themselves take time to run, and test results are unreliable to the point where it takes a human to investigate and interpret them.  When counting the time that it takes to both run and interpret results, test runs for an enterprise web site can take an entire day from inception to useful result.

    This session describes common points of failure in test execution that add both latency and unreliability and what can be done to overcome them while still preserving the value of UI validation.  We'll discuss why, after addressing these concerns, UI can be unblocked to reliably field thousands of validation scenarios on a local machine in a matter of minutes. 

  • Liked Tanay Nagjee
    keyboard_arrow_down

    Tanay Nagjee - Run your Selenium tests in a fraction of the time

    45 mins
    Talk
    Intermediate

    Comprehensive functional testing is a widely accepted best practice and Selenium is the prevalent tool of choice. But long-running Selenium test suites cannot be fit into short continuous integration (CI) cycles and are often run once a night or less. Running functional tests less frequently means bugs are discovered later than they should. Tanay Nagjee will discuss how Selenium test suites can be parallelized at a very fine granularity and included in CI builds. By leveraging a cluster of compute horsepower (on-premise and/or cloud), large Selenium suites can execute in a fraction of the time by smartly parallelizing the individual tests and running them on individual *cores* (not hosts). Tanay will outline the approach and tools to achieve these results with Selenium, and will present a live demonstration.


  • 45 mins
    Talk
    Intermediate

    Responsive Website Design have enabled mobile phones and tablets to fundamentally changed how we interact with the internet. Now we have instant access to any website we choose to visit and this causes headaches for testers, especially automated testers.

    This changes how automation, specifically Selenium, is implemented as the test suite needs to be maintainable, which is difficult and will get unruly if not maintained.

    The talk will be specifically about responsive websites however the same techniques can be applied to native app testing.

    Utilizing a test case generator allows for the test conditions(browser, OS and resolution) to exist outside of the test itself allows a single test to be able to test against all testing combinations without having to code for the other options explicitly. With the different options outside of the test the driver is easily instantiated and the browser windows are modified prior to test execution.

    As a sole(or two man team) automated test engineer for 4 years in over 5 projects these are my tools and techniques on how to make your automated test suite not only maintainable but adaptable to any device that you need to test with minimal overhead.

  • Liked Dipesh Bhatewara
    keyboard_arrow_down

    Dipesh Bhatewara - UI Automation As A Web Service

    Dipesh Bhatewara
    Dipesh Bhatewara
    Staff Engineer
    VMware Software
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    In modern cloud aeon, customers are delivered with UI and API for most of the Enterprise Products. The QE teams have to test the product for UI and APIs from functional as well as non functional perspective. For these they typically end up writing different test suites.

    There are lot of challenges one faces when automating test suites for these different purposes, like

    1. How do you integrate UI automation seamlessly with different test frameworks/suites?
    2. How do you test all these requirements (UI, API, Performance etc.) effectively without a lot of redundant or duplicate code?
    3. How do you use the best fit language/technology for UI automation and still do not impact the grand test automation strategies?

    There is an interesting solution to conquer these challenges which I have recently implemented in one of my projects. 

    The idea is to segregate tests from the UI Automation OR webdriver code. This code can be exposed as a web service APIs. Such service allows us to write common tests for UI as well as API. Tests written for API testing can be reused for UI testing with very minimal configuration modification like pointing to appropriate web service. These UI Automation APIs can also be called easily from any performance test requiring UI interaction.

    This approach will enable any test suite using any language or technology in your organization to reuse UI automation seamlessly. This will also make lot of things straight and simple for execution and management across the verticals.

     

    We will deep dive into the technical solution for this in this talk.

  • Liked Sarah Thompson
    keyboard_arrow_down

    Sarah Thompson - DevOps meets QA - Using Puppet to set up and manage your Selenium Grid

    Sarah Thompson
    Sarah Thompson
    QE UI Toolsmith
    Puppet Labs
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    For testers, setting up and maintaining a Selenium Grid infrastructure can be timely and costly. A lot of the time, we are asked to do this as part of our day to day job when we really want to focus on testing the product!

    There are some great cloud based alternatives out there that allow you to easily run your tests on a wide range of Operating Systems and against multiple browser types (at a price).

    But what if you already have plenty of devices available within your own company (be it physical machines, virtual machines or cloud based resources) and you want to be able to setup and manage your own grid infrastructure:

    • to allow you greater control over the configuration (perhaps you want to have a headless browser like PhantomJS available on your grid)
    • to run your tests faster (the cloud based alternatives are a good bit slower for obvious reasons)
    • or to simply save money.