The Behavior Chromosome

The first time I’ve experienced this enlightening moment was when I discovered Behavioral Driven Development or BDD. It was clear from the beginning that the proposal of BDD to express test scenarios in a common -subset of English- language shared among the three most important actors in any software development project (product owner, developer and tester), was the right choice to pursue in any project. The survival of BDD and its spread across the field -even to unit test frameworks- shows this was the right intuition.

This crystal clear executable example of BDD test talks by itself:

Feature: Login in the application



Scenario: User can login with valid user name and password

Given I see the login page

When I enter the user name "sebas" and password "passion"

Then I see the welcome page

Why?

Clear expectations. When product owners, customers, testers and developers share the same expectations about how an application should look and behave, both the development speed and the quality of the product experience a drastic improvement.

She really wants to be free, let her go.

Large projects tend to accumulate piles of tests that nobody cares or knows what they are supposed to test. These tests are kept untouched like sacred cows to respect the code coverage, but the truth is that code coverage is good for code quality and low level bug squashing, while it does little to help build the right application or cover real use cases (especially when coverage comes mainly from unit tests). Like legacy code, legacy tests should also be re-factored and often deleted.

On the other hand, clear documentation is often confused with just lengthy specifications that most of the times bring more boredom and avoidance than clarity and consensus to the project’s team.

Therefore, we can easily arrive to the logical conclusion that clearly written expectations in the form of tests -even manual tests- essentially become the most up to date and relevant documentation of the application’s look and behavior. You may think that living documentation written in the form of automated tests sounds more like a magical fantasy than a truly evolutionary step, but the truth is out there and RSpec is one of the many great examples of executable documentation.

How?

Surprisingly easy. There are many BDD frameworks available for almost every language, in this article I will use Cucumber. This library simply transforms English written sentences contained in feature files into methods implemented in your preferred language -Java in our case-.

The best way to explain this is with an example that wraps your typical test function into a reusable and meaningful English sentence.

Here is a Cucumber feature file with a complete test scenario:

Feature: Login in the application @ScenarioId("MyApp-135") @login-scenarios

Scenario: User can login with valid user name and password

Given I see the login page

When I login with user name "Sebas" and password "pasión"

Then I see the welcome page

And the title is "Welcome Sebas"

And here is the Java glue code for the last test step of the scenario above:

@And("^the title is \"(.+)\"$")

public void the_title_is(final String title) {

assertTrue( title.equals(LoginViewModel.getTitle()) );

}

The first keyword in the sentence is interchangeable with: Given/When/Then/And

One important feature of Cucumber is that it allows you to mark your test scenarios with custom tags. It is very important that you tag your tests, mostly to trace features and User Stories of your product back to the tests that cover them. This has the extra benefit that executions can be filtered based on these tags (e.g. run only @login-scenarios).