Notes on Angie Jones, Make Your Automation Behave: Extending Your Framework for BDD (June 28, 2017)

Notes, Make Your Automation Behave: Extending Your Framework for BDD

Given by Angie Jones, held on Jun 28, 2017  

Recording: A Software Test Professionals Webinar (STP)

"When done properly, Behavior-Driven Development (BDD) can drastically improve the communication and understanding of requirements. An additional benefit is being able to utilize the domain-specific language of the requirements to drive test automation. However, like any other automation initiative, when done poorly, this too can fail.

"In this webinar, Angie Jones provides a hands-on technical look into how to:

• "utilize Gherkin-written scenarios for test automation
• "write scenarios in a way that promote maintainability and reusability
• "take advantage of advanced Gherkin functionality such as data tables and objects
• "tie the scenarios to automation code
• "incorporate this approach into existing automation frameworks that use the page object model design pattern
• "share state across multiple steps within a scenario

"Upon completion of this webinar, you’ll have a better understanding of how to:

• "Enhance your BDD initiative with test automation
• "Cleanly extend an automation framework to support executable requirement specifications
• "Support advanced techniques such as data tables and objects within specifications, as well as sharing state through dependency injection".

The Speaker:

"Angie Jones is a Senior Software Engineer in Test at Twitter who has developed automation strategies and frameworks for countless software products. As a Master Inventor, she is known for her innovative and out-of-the-box thinking style which has resulted in more than 20 patented inventions in the US and China. Angie shares her wealth of knowledge by speaking and teaching at software conferences all over the world".

Speaker Contact Details:

Angie Jones – Senior Software Engineer in Test, Twitter
Twitter: @techgirl1908
LinkedIn: Angie Jones
Website: AngieJones.tech

STP will be hosting a software testing conference, STPCon, on September 25 - 29, 2017 in Washington, DC. You can register at http://STPCon.com/event-schedule

Angie gave a Q&A session to the Ministry of Testing - Boston Tuesday, 11, 2017 at https://www.meetup.com/ministry-of-testing-boston/events/240813119/

Recording: Make Your Automation Behave

Slides:

Looking to add BDD to your test suite?

You do not have to abandon your sturdy old framework to implement BDD. You can simply extend it! 

The Page Object is the industry design standard, modeling an object on the page you are testing, encapsulating how to interact with radio buttons or textboxes. You then create public methods that interact with these private methods. These methods can be used in your tests. 

Behavior Driven Development:

• The Three Amigos, a QA, DEV and Product owner discuss how a certain feature should behave. You can describe it in the Gherkin style language. 

Want to read how George Dinwiddie, Agile Adoption Coach, came up with the concept of “The Three Amigos”? 

• Read his The Tree Amigos Strategy of Developing User Stories https://www.agileconnection.com/article/three-amigos-strategy-developing-user-stories (April 24, 2014). 
• See LinkedIn profile https://www.linkedin.com/in/gdinwiddie/ Blog http://idiacomputing.com/

See Dan North, creator of the Behavior Driven Development (BDD), and JBehave, and then RSpec, being interviewed at OOPSLA 2007. https://youtu.be/qWsnmx45734 

• Cucumber started off as being a compliment to RSpec and Dan North’s work. 

Let’s say you have two source branches of your code:

• src/main/java
• src/test/java

Your main branch can contain the page objects. The test branch can contain the packageds cucumber -> features.

Install the Cucumber plug into your framework’s Maven or Gradle files. If you go to Cucumber.Io it has documentation how to do this. 

You can have as many feature files as you want. 

Feature: Search for Products

   As a user, I want to search the catalog so that I can find specific products

Scenario: Click search result

   Given there is a product named ‘Apple TV’

   And I search for the product

   When I click the product

   Then I should be taken to the product page

This feature file acts as manual documentation for how the software product is supposed to work. 

Givens: Setup before the test starts

When: The actual test

Then: The results of the test. 

Note that we don’t have any extraneous details, where to click, how to see the product is Apple TV. Testers can be a bit long-winded being too explicit what each step means. 

Push the details down to the code level. 

Under src/test/java/cucumber, Angie likes adding two directories:

• features
• stepdefs

The “features” folder contains the outlines for the scenarios. 

One steps definitions per functional area keeps things clean. 

These are all you need for Cucumber. You can use your already written Page Objects into your tests. 

public class SearchStepDefs {

   protected String productName;

    

   @Given(“^threre is a product named (.*)$”)

   public void setProduct(String productName) {

       this.productName = productName;

   }

}

@Given, @When, @Then, are annotations borrowed from Cucumber. 

@When(“^I search for the product$”)

public void search(){

   Page currentPage = new Page(BaseTests.getWebDriver());

   searchResults = currentPage.search(productName);

}

… Angie is using the getWebDriver() method already declared in her framework to spin up a new WebDriver. 

A new instance of the page is spun up, in order to create a search method. 

@When(“^I click the product$”)

public void clickProduct(){

   currentPage = searchResults.clickProduct(productName);

}

Note, we are NOT dealing with elements in our step definitions just as we do not deal with them in our test classes. Keep it clean! 

Let’s create a new method… clickProduct… and put it in our ProductPage. 

public ProductPage clickProduct(String productName){

   WebElement product = findProduct(productName);

   product.findElement(productTitle).click();

   return new ProductPage(webDriver); 

@Then(“^I should be taken to the product page$”)

public void verifyProductPage(){

   ProductPage productPage = (ProductPage)currentPage;

   Assert.assertEquals(“Page title”,productPage.getTitle());

}

We are using existing code in our step definitions. 

Let’s try a different scenario:

Scenario: Add the product from search result to cart

   Given there is a product named Apple TV

   When I search for the product 

   And I add the product to the cart

   Then the product should be in the cart

We don’t want to add cart step definitions to our search step definitions… that becomes messy and unorganized. Yes, it is a search test, but we really should create CartStepDefs, adding it to BaseStepDefs and SearchStepDefs. Cucumber can search through our library of Step Defs. 

Therefore, we can write:

public class CartStepDefs {

   @Then(“^the product should be in the cart$”)

   public void verifyProductInCart(){

      CartPage cartPage = new CartPage(BaseTests.getWebDriver());

      Assert.assertTrue( productName + “is in cart”, cartPage.isProductInCart(productName));

      Assert.assertEquals( “Number of items in cart”, 1, cartPage.getNumberOfProducts(());

   }

}

How do you share data across multiple steps and multiple classes? Dependency Injection!

Pass a dependency to whoever needs it. Create a BaseStepDefiniton that holds globals that will be needed across all steps, such as the productName variable. 

public class BaseStepDefs {

   protected String productName;

   protected Page currentPage;

   public BaseStepDefs() {

   currentPage = new Page(BaseTests.getWebDriver());

   }

    

   @Given(“^there is a product named (.*)$”)

   public void setProduct(String productName) {

       this.productName = productName;

   }

}

… Now we need to inject this in the class that needs this dependency. 

There are many ways you can set up dependency injection. Angie Jones likes using pico container in Spring. 

Check in Cucumber.io on how to do this. 

Add a constructor to each of the dependent classes, then include the dependency as an argument. 

Happy Testing!

-T.J. Maher
Twitter | LinkedIn | GitHub

// Sr. QA Engineer, Software Engineer in Test, Software Tester since 1996.
// Contributing Writer for TechBeacon.
// "Looking to move away from manual QA? Follow Adventures in Automation on Facebook!"