Advancing Readability

How many times have you come across an automation test where it simply flowed beautifully off your lips with complete clarity? Or consider tests having the fluidness and grace of a relaxing stream, peacefully traveling through nature? I would say, it’s remarkably rare. 

And what I am referring to, is readability. I believe test should have these types of characteristics and attributes associated with them. 

Examples litter the internet, promoting page object design with fragment statements, choppy commands and multiple-line block assertions; furthermore, it seldom addresses readability and leaves the reader perplexed and confused on what is happening within the test.

The documentation defines page object as, an object that models a web page or web component and provides that single location when change occurs; in addition, the page object should expose “services” back to the test. 

Despite the great power page objects furnishes, the design does not provide all the mechanisms necessary to construct tests with all the characteristics described above.

To achieve this level of readability, required new thinking, a new approach, and a new design. A design that is flexible, easy to implement and works with the current page objects already in your project. Welcome to H.P.A. — 

Handlers

Provides the fluidness as the test moves from page object to page object, by displaying visual clues where the reader is within the application

Page Objects

Page Objects continues the traditional role except for methods returning another page object, they instead return a handler

Assertions 

Drives clarity and exposes "expectation of correctness” within the test, similar to page objects, by revealing assertion methods to the reader.

Currently, the design has been implemented across numerous applications from typical multiple page application to SPAs (Single Page Application), while allowing the developer more flexibility to adjust  and fit the correct approach to his/her given situation. For example, within SPAs, there are times when a handler or an assertion class is unnecessary. With HPA, there are no hard rules that must be followed, or strict framework coding conventions.

View and Checkout an Working Example @ https://github.com/5hawnknight/hpa-design-example

Below is example of a HPA design and some typical tests --


H.P.A Design Test - 

public void test()
{
       myApp()
                  .home()
                      .header()
                          .selectAccountButtonAsVisitor()
                               .logInAsUser(person)
                  .home()
                      .header()
                          .openSideNavigation().selectLibrary()
                  .library()
                      .searchAndOpenEPubInReader(epub)
                  .readerPage()
                      .getReader(epub)
                  .reader()
                      .leaveReaderPane()
                  .readerPage()
                        .header()
                            .selectAccountButtonAsUser()
                                 .signOut();
      assertions().readerPaneAssertions().verifyReaderPaneIsNotDisplayed(epub);
}

Typical Tests -
public void test()
{
   Login login = new Login(driver);
   login.typeUsername("userX");
   login.typePassword("pwX");
   Dashboard dashboard = login.submitLogin();
   dashboard.typeDestination("Canada");
   SearchResults results = dashboard.submitSearch();
   Assert.assertEquals(true, 0 < webDriver.getPageSource().indexOf("Search Tag"));
}

or

  public void shouldBeAbleToSearchForCats() {
      searchPage.open();
      searchPage.searchFor("cats")
                .selectsCategory("Pets")
                .shouldDisplayTitlesWith("cats");
}