In software engineering, behavior-driven development (BDD) is an Agile software development process that encourages collaboration among developers, QA and non-technical or business participants in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD is NOT for Testing but Testing is part of BDD

As mentioned, BDD is a development model that follows the Agile methodology. Agile teams benefit from the cross-communication between not only team members but also stakeholders (clients) within the business. Agile teams generally work on one project at a time and routinely have short meetings to discuss each individual’s progress and sticking points.

Core concepts

Ubiquitous language
Given-when-then
Value and complexity analysis

The idea was to combine automated acceptance tests, functional requirements and software documentation into one format that would be understandable by non-technical people as well as testing tools. For that Gherkin language can be used.

In the book Specification by Example, Gojko Adzic nicely explains the BDD approach. If you want a handbook, BDD in Action by John Ferguson Smart is highly recommended.

Communication, collaboration and automation are the 3 pillars of BDD, regular Three Amigos sessions (business persons, developers, testers) are a great tool to come up with examples of how the software should behave, and write them down in Gherkin syntax.

Team members have conversations early to discuss business needs and possible solutions.

Collect business rules and write down the examples to make it clear for everyone.

The examples are bracken down into steps which lead to consequences to validate the original business rules.

Following BDD’s flow let’s show the above described actions in an example, using our training environment: PetstoreUI

Requirement

As a logged in user

I want to be able to create different kind of pets

And tag them to find them easier

Practical Examples

Examples are an effective way to understand requirements and edge cases.
Summarize test data or expected results
Improve readability

Expressive examples in table format

	name	category	tag

	name	category	tag
bunny	Buggs Bunny	Bunny	female
fish	Funny Fish	Fish	male

Practical Examples in CAST

The table can be transformed easily into CAST language: xml, that is easy to read, store various data and extend.

<data id="petsToAdd">
    <petstore>
        <bunny selector="${selectedPet}">
            <name>Buggs Bunny</name>
            <category>Bunny</category>
            <tag>female</tag>
        </bunny>
        <fish selector="${selectedPet}">
            <name>Funny Fish</name>
            <category>Fish</category>
            <tag>male</tag>
        </fish>
    </petstore>
</data>

Scenario Writing Based on Steps and Consequences

Scenario name as Summary in XRay Test ticket, define it with xray:testSummary attribute of Scenario in CAST
- Describes the business context or situation
- What does the user want to do?
- What business rule are you illustrating?
Given, When, Then as steps in XRay Test ticket
Add free-text descriptions to Scenarios using Description field in XRay x:ray:testDescription in CAST

Scenario Writing in CAST

The previous Jira extract is generate by CAST, using export function. The scenario looks like the following in CAST:

The xray:stepDescription is described with Gherkin syntax and can be completed with additional test data or expected result

<sui:scenario
        id="ot:addPetScenario"
        xray:testDescription="Login to the pet store, add two pets and log out"
        device="${@chrome()}">
    
    <test-step xray:stepDescription="Given I am logged in to PetstoreUI" xray:stepData="" xray:stepExpectedResult="">
        <loginStep />
    </test-step>
    
    <test-step xray:stepDescription="When I navigate to the Pets Page" xray:stepData="" xray:stepExpectedResult="">
        <sui:click pageId="navPetsButton"/>
        <sui:wait-for-url method="equals" timeout="8" value="${@config('petstore.petsUrl')}"/>
    </test-step>
    
    <test-step xray:stepDescription="And I add a pet" xray:stepData="" xray:stepExpectedResult="">
        <addPetStep />
    </test-step>
    
    <test-step xray:stepDescription="Then the Pet appears in the store" xray:stepData="" xray:stepExpectedResult="">
        <checkNewPetStep />
        <logoutStep />
    </test-step>
    
</sui:scenario>

Feature

A Feature represents a deliverable piece of functionality
A feature contains one or more scenarios
There is no direct representative of features in XRay, we can use Test Plan or Test Set
In CAST, we can group tests or run them in one Test Suite (test suite in CAST is a test plan in XRay)

Features in CAST

<suite id="demo-test-petstore:addPetSuite"
       jira:projectKey="DEMOTESTS"
       xray:testplanKey="DEMOTESTS-993"
       xray:testplanSummary="Feature: Create New Pet"
       xray:testplanDescription="As a logged in user I want to be able to create different kind of pets And tag them to find them easier">

    <ot:addPetScenario xray:testSummary="Scenario: Add Bunny to store" selectedPet="bunny" xray:testId="DEMOTESTS-991" />
    <ot:addPetScenario xray:testSummary="Scenario: Add Fish to store" selectedPet="fisch" xray:testId="DEMOTESTS-992" />

</suite>

Background

Run before each scenario
Avoid repetition
Help focus on the important stuff

Backgroung in CAST

In XRay we have a special ticket pre-condition for this purpose, but it CAST, for reporting reasons it is a separate test or test step

Grouping common scenarios to use the same with different input data / expected result is a great example for https://jira-testifi.atlassian.net/wiki/spaces/CTF/pages/2925887636

Benefits of BDD

Keep everyone involved and on the same page
Deliver functionality that users really need
Eliminate wasted time

Challenges of BDD

There are people who have misunderstood this concept of BDD. Some of them use Gherkin as a testing tool and BDD as a testing method. Some write features after the development of their software product in order to reflect its behavior. Although everyone has the freedom to use these tools as they wish, this crowd is missing the bigger purpose of this collaboration tool, creating a shared understanding among three amigos by discussing examples on expected software product.

Using CAST in Behaviour Driven Development