Behavior-Driven Development applied to automated testing projects

Behavior-Driven Development (BDD) was originality developed by Dan North by 2006 [1] and is basically a philosophy, a procedure, a concept about how software development should be managed by all member of a project from business interests to the software developers that implements the code. BDD combines the general techniques and principles of Test-Driven Development (TDD) with automated acceptance tests [2] to provide a complete software development.

Where TDD is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass the test, and finally refractors the new code to acceptable criteria [3][4]. On the other hand, we understand that in an automated acceptance test procedure software developers and stakeholders collaborate to write automated tests that express the outcome that the stakeholder wants. In this sense, a key point in BDD procedure is the ubiquitous language. This is a semi-formal language that is shared by all members of the software project becoming a vehicle for the communication between all the different roles. The language, called Gherkin, is formed by specific word such as:  Feature, Background, Scenario, Given, When, Then, and, But, Scenario Outline, Examples,…[2][5]. The physical implementation of the ubiquitous language is the feature file. This is a standard file (created for example with a notepad) wherein, using the mentioned words, test cases are written forming sentences. The simplest structure of a feature file is [2]:

Feature: Specification of the test case.

Scenario: Test case. Each scenario contains steps.

Given: To set up the context or the preconditions where the scenario happens.

When: To interact with the system somehow. Action to do.

Then: To check that the outcome of that interaction was what we expected.

A feature is a place to write the summary documentation about the test suite that follow. A scenario express the behavior that we want, each feature can contains several scenarios. Each scenario is a single concrete example of how the system should behave in a particular situation. Finally, each scenario is described by sentences using the mentioned key words. It is important to mention that sentences can include input variables to describe particular test situations or expected results (see figure 1).

BDD automated testing general procedure

Usually, to create a project with a BDD procedure we need use specialized software tools (Cucumber is possible the most popular [2]) to support the development process. Although we can use these tools, the global process of BDD can be implemented without the use of them but for it you must implement your proper tool. In the next a simple procedure to create it is presented.

Figure 1: Equivalence between sentences in scenario and label in functions in the library.

The first step is to create a feature file wherein each sentence in the scenario represents an action applied over the system that necessarily must be transformed in a block of code. In turn, the code is a set of recorded actions that can be generated using automated testing tools (such as UFT, Visual Studio or Squish amongst others). The easiest way to organize this information is creating a library where all the possible recorded actions are stored in different functions (see figure 1).

But, how the connect the sentences in scenario with the functions in library? We need something to connect both parts and this is precisely the key point of all the procedure. We need a “driver”.  This BDD-driver is a script that is written in the programming language in which you are working (JavaScript script, Visual Basic …). A possible scheme of its operation is shown in the following figure:

Figure 2: Schematic diagram of a BDD-Driver

The programming behind the script is not complicated.  First, as it is shown in figure 1, we associate for each function in library a label that corresponds with the sentences of scenario. On this manner, each sentence in scenario corresponds to a function in library. A simple algorithm to implement the BDD-Driver is shown in figure 2. Here, you must read the library file to save in a matrix both the label and the name of the function. For this purpose you need a function to parse lines in files since you only must save the label, the possible input variables and the name of the function deleting the rest. When the matrix is created the next step is to read line to line the feature file. The algorithm follows comparing each sentence in feature with the elements of the matrix to find the same sentence in the library until the label is found. Finally, we run the function and the corresponding action over the studied system.  The algorithm works until all the sentences in all scenarios in feature has been executed.

In conclusion BDD can improve significantly the progress of a project of automated testing reducing its costs and increasing the productivity. Several are the reasons. First, once the function library is created you have at your disposal all the necessary sentences to create feature files. On this manner anyone can design of an easy way a set of features to test the different functionalities of an application. Also, a code level this procedure provides a set of advantages such as a clear modular programming, solid architecture, and an easy maintenance.

References:

[1] http://dannorth.net/introducing-bdd/

[2] The Cucumber Book, M. Wynne and A. Hellesoy, (2012)

[3] http://en.wikipedia.org/wiki/Test-driven_development

[4] Test Driven Development: By Example, Kent Beck, Pearson education (2002)

[5] Domain-Driven Design: Tackling Complexity in the Heart of Software. Evans, Eric (2003/2012)

Más información:

Alfonso Alarcón – Ingeniero de Test – Sogeti España

alfonso.alarcon-pardo@sogeti.com