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.
Congratulations on the new job!
ReplyDeletePart of it is replacing a Delphi system!
ReplyDelete