How to Optimize Behavior Driven Development for Software Testing

According to Dan North, the creator of Behavior Driven Development frameworks like JBehave and RBehave, “Behavior Driven Development (BDD) is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters. To put it in simpler terms, Behavior driven approach focusses on delivering agile software solutions that result in higher business yield with lesser flaws and better quality. Behavior driven approach encourages and facilitates higher collaboration between teams and respective stakeholders.

How you can determine BDD Approach for your Testing process

Despite the advantages of automated testing, it is not practically wise to automate all test scenarios, since there are costs involved with every automation effort.
Some scenarios where one is better-off with manual testing are:

• If a test needs to be executed only for a few times.
• If the application is likely to change soon (especially in the case of GUI).
• If, during its lifetime, a test is less likely to find any new bugs.

Creating scripts for automated testing requires time and effort. When the application undergoes changes, the test scripts also need to be changed accordingly, otherwise the tests break. Further, testing efforts are constrained by resources of time and number of test automation engineers. Hence, “Which scenarios to automate?”is a question that is as important as “How to automate ?”

Let us examine these questions more closely:
“Which scenarios to automate? “
This relates to the business value of a feature in the application. Business Analysts are the right people to answer such questions.

“How to automate?”
Test Engineers are the best people for this task. Wouldn’t it be nice if these responsibilities could be delegated to the right people? This is where BDD comes into the picture. Using BDD, not only are these responsibilities delegated, but the features are also written in such a way, that all the stakeholders can discuss about it, before even a single piece of test automation code is actually written.

Using ‘Behave’ framework for BDD approach

Behave is a BDD tool that supports Python, which we are using for our automated-testing purposes.
We have the following test environment-

• • Application under test (AUT): Web application GUI developed using HTML5
  • Scripting Language: Python
  • Testing Tool: Selenium

For this test environment, “Behave” suited us perfectly.

A Simple Demo for Behavior Driven Testing

For demonstration purpose, let us take an example of an application that checks whether a number is prime or not.

Features Document

The Features document could look something like this

It is written in simple English language. No technical knowledge is required to understand it.This language is known as “Ghecko”.

In this Scenario Outline, a list of input and output values are provided. This specification says that, for each input_value, the expected output should be same as the corresponding output_value. E.g, when the input is 3, then the expected output is “Prime”. This list can be modified at anytime. Test case gets executed for each value in the list.The 1st scenario says that, for a non-integer input value “dummy”, application must throw a TypeError exception

The 2nd scenario says that, for a negative value like ‘-1’, the application should return “Neither Prime Nor Composite”.

Several other scenarios can be described in a similar way.After all the stake holders agree upon the set of features to test and their priority, test-automation team starts the test method implementation.

BDD Test Method Templates

The test engineer creates a structure as follows:

All the feature files are placed inside “features” folder.The test-case implementation files are created inside “features/steps” folder.After executing “behave” command, behave generates templates for the test methods.For our prime number example, behave will generate templates as below:

The Test Engineer uses these templates and implements them in a Python file, inside the “steps” folder.

Test Method Implementation

An implementation of the “Scenario Outline” looks like:

Test automation team need not implement all the scenarios present in the feature file. It can be done on a priority-basis.

Report

When behave is executed, it shows the results for all the implemented scenarios and provides template methods for the unimplemented ones.
Other useful information present in the report include:

• • • Test-case Result : Passed or Failed along with the test-case parameters
    • Test-case execution time.
    • Count of features passed, failed and skipped.
    • Count of scenarios passed, failed and skipped.
    • Count of steps passed, failed and skipped.
    • Total time taken for test-case execution.

For our prime number example, after implementing only the scenario outline, the behave report looks like

For the unimplemented steps, templates are provided in the report:

Conclusion : BDD Approach Fosters Engineers and Stakeholders’ Alignment

Behavior-Driven approach tries to make test-scenarios easy to read and maintain. It aids in easy communication between engineers and business stakeholders. In real-world scenarios, where there are complex applications and numerous features to test, this approach becomes more significant. Some quick points to summarize:

• Readability counts
• If the implementation is hard to explain, it’s a bad idea.
• If the implementation is easy to explain, it may be a good idea.

References
https://en.wikipedia.org/wiki/Behavior-driven_development
http://pythonhosted.org/behave/