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.