Month: June 2014

BDD and JBehave

I’ve been in my new job for a few weeks now and encountered Behavior Driven Development in the code I’m looking at, using JBehave.

BDD is a way of structuring unit tests in such a way as to make them more human-readable. Typically, a conventional unit test looks something like this (this is for a small builder class I’ve created):

@Test
public void testOneWhere() {
    //select with one criteria
    SQLBuilder instance = new SQLBuilder();
    instance.select().table("A_TABLE");
    String result = instance.where("A_COLUMN", "A_VALUE").build();
    assertTrue("result is not proper SQL: " + result,
            result.equals("SELECT * FROM A_TABLE 
                           WHERE A_COLUMN = \"A_VALUE\""));
}

This is quite a small test, but it’s easy to see that someone non-technical would have difficulty following what was going on here. Plus it’s not very flexible: if you want to test boundary conditions, for example, you either have to do a lot of cut-and-pasting or some fancy footwork with the test libraries.

Compare this to the equivalent BDD statement (called stories):

Scenario: with a where clause

Given a new SQLBuilder object
When select is called
And table is set to A_TABLE
And where is set to A_COLUMN equals A_VALUE
And build is called
Then the result is SELECT * FROM TABLE WHERE A_COLUMN = "A_VALUE"

This is supported in the test harness by methods bound to the statements in the story:

@When("select is called")
public void selectIsCalled() {
    sqlBuilder.select();
}

@When("table is set to $table")
public void tableSetToTable(String table){
    sqlBuilder.table(table);
} //etc.

Not only is the story more readable, but you can parameterise the calls, setting up tables of inputs and expected outputs. Nice.

It’s disdvantages seem to be that it does not have stories that can define throwing exceptions, but the idea is that exceptions should not occur at this level and should be handled lower down. Finer grain unit tests would probably handle this.