Community

Deliver better software faster with Behavior Driven Development

Share this post:

In the context of digital transformation and dramatic acceleration of software deployments, working in silos (Business, Developers, Testers, IT…) is no longer an option. Agile, and now DevOps culture, are getting a lot of traction as they break silos with cross functional teams. Therefore, rapid iterations and quick feedbacks are king.

For organizations deploying new software in production several times a day, one of the most challenging transformation issues is the need to revolutionize testing. In an era of continuous deployment and updates, there’s no time to have QA teams identify a problem and kick it back to the developers. The times are gone when you could test your app after the development and before going in production.

This is where Behavior Driven Development (BDD) comes in. BDD is a powerful approach that enables your team to align on the definition of what should be built, and when.

First, the developers, testers and business analysts explore the problem domain, and collaborate to produce concrete examples that describe the behavior they want.

Every test should tell a story about your application

These examples define the boundaries of the user stories and are designed prior to the development. It’s a great way to minimize waste and avoid development of features that are not needed, or that do not meet business expectations.

These concepts are quite simple and were initially formalized by Dan North.

Using BDD with Gherkin syntax

Gherkin is plain-text language with extra structure included to make it easy to learn by non-programmers. It allows concise description of examples to illustrate business rules in most real-world domains. One of the biggest advantages is that it clearly highlights the intent of the example/test development application.

You can follow these basic steps to begin using BDD and Gherkin syntax:

  1. Start with your user stories.
    • As a team, go through your user stories and write BDD scenarios using the keywords GIVEN, WHEN, and THEN (AND, BUT can be used as well)
    • GIVEN is your setup. For example: “GIVEN the credit card is valid”
    • WHEN is your action. For example: “WHEN I request $50”
    • THEN is your assertion: For example: “THEN the ATM should dispense $50”
    • Capture the BDD scenarios in a location that is public for everyone to see. Hiptest is a good choice 🙂
  2. Automate your BDD scenarios.
    • First, the execution will fail as the feature is not yet implemented
    • Automation clearly requires development skill. You’ll want to learn how to build a test automation framework that scales.
  3. Implement the features
  4. Run the automated BDD scenarios to show the feature is completed
  5. Repeat

Here is a sample Gherkin document:

<span class="k">Feature:</span><span class="nf"> Account Holder withdraws cash

Scenario: Account has sufficient funds
Given the account balance is $100
And the card is valid
And the machine contains enough money
When the Account Holder requests $20
Then the ATM should dispense $20
And the account balance should be $80
Then the card should be returned

The next post will focus on a step-by-step implementation of BDD with Bluemix and Hiptest.

If you have any questions, or would like to chat further about BDD please reach out to support@hiptest.net.

More Community stories

Db2 on Cloud Announces Disaster Recovery Node

The Db2 on Cloud team is excited to announce Disaster Recovery (DR) capabilities for Db2 on Cloud. It leverages Db2's HADR technology and lets users add a DR Node on demand in an offsite data center of their choice. In an unlikely event where the primary data server is affected by external circumstances, such as a natural disaster, users can failover to their Geo-Replicated Disaster Recovery Node with a few clicks.

Continue reading

The Countdown Is On: Upgrade to VMware vSphere 6.5 Now!

Are you currently running VMware vSphere 5.5? Whether your workloads are on-premises or in a cloud environment, the time to upgrade to vSphere 6.5 is fast approaching.

Continue reading

IBM Runbook Automation Experimental Cloud Deprecation

As of August 6, 2018 the Runbook Automation Experimental service tile will be removed from the IBM Cloud Experimental catalog. New users will no longer be able to provision the service, but the existing customers' instance will be active until September 7, 2018.

Continue reading