Als een groot aantal ontwikkelaars aan één ding een broertje dood hebben dan is het wel aan testen. Hoe krijg je die zelfde ontwikkelaar dan aan test-driven development? Simpel, je vermijdt te allen tijde het woord test. Dus test-driven development wordt behaviour-driven development en je vervangt het unit-test framework JUnit door JBehave.

Behaviour driven development (BDD) wordt gezien als de volgende evolutionaire stap in het lijstje van test driven en acceptance driven development methodieken. Het is geen revolutie en wijkt ook niet zo heel veel af van Test driven development (TDD). Het grote verschil is dat BDD zich meer richt op verificatie van gedrag en TDD richt zich meer op verificatie van code. TDD is meer whitebox testen, waarbij in de code gekeken wordt om te zien welke testen er nodig zijn, en BBD meer blackbox, waarbij alleen naar de input en de output van het programma gekeken wordt.

Om een andere manier van ontwikkelen te rechtvaardigen moet er iets mis zijn met TDD. Het meest gehoorde probleem van ontwikkelaars is dat niet altijd duidelijk is welke code getest moet worden en hoe die testen dan moeten gaan heten. Al snel beslaan de testen niet meer dan het controleren van grenswaarden. TDD richt zich teveel op het testen en daardoor wordt uit het oog verloren wat het programma nu eigenlijk moet gaan doen.

BDD pakt het testen op een hoger niveau aan. Het richt het testen vooral op het gedrag van het te ontwikkelen programma. Dit gedrag komt rechtstreeks uit het functionele ontwerp. Simpel gezegd wordt elke zin waarin het woord “moet” of “zal” voorkomt te controleren gedrag. Uiteindelijk levert dit een aantal controles op die heel erg dicht bij een volledig testplan zullen liggen.

Is er voor BDD een ander testframework nodig dan JUnit? Eigenlijk niet. Het belangrijkste is dat elke verificatie een logische naam krijgt die beschrijft wat er gebeurt. Zeker nu in de nieuwste versies van JUnit niet elke methode meer met methode verplicht met test moet beginnen is er meer vrijheid. JBehave, een testframework wat ontworpen is om BDD te ondersteunen, gaat nog wat verder door de hele test als een normale zin te laten lezen. Binnen de grenzen van wat Java toestaat zou een testmethode er dan zo uit kunnen zien:

public void moetWaardesInOmgekeerdeVolgordePoppen() throws Exception {
  stack.push("waarde 1");
  stack.push("waarde 2");
  Ensure.that(stack.pop(), m.is("waarde 2");
  Ensure.that(stack.pop(), m.is("waarde 1");
}

JBehave maakt gebruik van matchers (m in de listing) die bepalen hoe de verwachte waarde tegen de actuele uitkomst gecontroleerd moet worden.Het idee hierachter is dat een meer gezamenlijke taal gebruikt wordt die door zowel de projectleiders, de ontwerpers, de ontwikkelaars, de gebruikers en de domeinexperts kan worden begrepen.

Het andere belangrijke punt is dat er eerst wordt nagedacht of het gedrag zoals dat staat beschreven helemaal duidelijk is. Met BDD schrijf je geen tests, maar schrijf je specificaties waaraan de code moet voldoen.

BDD is zeker geen revolutie voor diegene die al gewend zijn om de op te leveren code te voorzien van unittests. Alle patterns die bij TDD belangrijk zijn, zoals bijvoorbeeld mockobjecten, zijn bij BDD ook van belang. Wel benadrukt het nog een keer dat het functionele ontwerp klaar moet zijn voordat er daadwerkelijk aan het bouwen kan worden begonnen en dat het bouwen van software begint met het maken van tests. Met welk framework dat gebeurt is niet zo belangrijk; als het maar gebeurt.

Zie ook: www.behaviour-driven.org en jbehave.org

—————————————————————————————
Meer weten over Java-specialist Finalist IT Group?