BDD (Behaviour-Driven Development) maakt het mogelijk acceptatiecriteria voor een stukje software te testen. In deze blog laten we zien hoe je met Spock code kunt testen volgens het BDD-principe.

De wortelfunctie getest in Spock

Laten we uitleggen wat BDD is aan de hand van een voorbeeld. We gaan de sqrt-functie testen. Dit is uiteraard niet nodig (we gaan ervan uit dat Oracle deze functie al goed getest heeft), maar ter illustratie hoe je een test met Spock opzet.

De sqrt-functie biedt de wortel van een gegeven getal. Hieronder zie je een testscenario voor de sqrt-functie.

acceptatiecriteria sqrt-functie
De sqrt-functie moet wortels kunnen opleveren voor een gegeven getal.
Scenario: De wortel van 9 moet 3 zijn
Wanneer: de invoer 9 is
Dan: zal het resultaat 3 moeten zijn

Als we voor dit scenario een test willen schrijven in Spock, ziet dit er als volgt uit

De wortel van 9 moet 3 zijn, zou natuurlijk ook zo een testscenario kunnen zijn voor een userstory.

Goed om te weten, Spock tests draaien in Groovy. Dit:

is dus gewoon een method definitie.

Omdat we vrije namen kunnen gebruiken, kunnen we hier dus ook acceptatiecriteria als naam opvoeren. Verder zien we een given, when en then in de functie staan:

• given: is om aan te geven wat de uitgangssituatie is die je wil gaan testen. In ons voorbeeld een getal met de waarde 9.
• when: de aanroep die je wil testen. Nu de aanroep van Math.sqrt.
• then: definieert de verwachte situatie na uitvoer van het when-gedeelte. In dit geval controleren we of dat wortelVanNegen inderdaad 3 is.

Data driven testing

Wat nu als we de wortelfunctie willen testen met meerdere waardes? In onderstaand voorbeeld voeren we verschillende getallen in de functie in en controleren of het verwachte resultaat ook geleverd is door sqrt.

Draaien we deze test in IntelliJ, dan zien we ook netjes dat de testen zijn uitgevoerd met de verschillende waarden.

Spock
Hieronder zie je de complete test class.

Test-classes in Spock heten Specs dus is de naam niet TeTestenKlasseTest maar TeTestenKlasseSpec. Overigens ben je vrij om hier toch Test van te maken. Maar aangezien we met Specs testen, is het wel zo netjes onze tests dan ook Spec te noemen.

Hoe kunnen we Spock in een Maven-project gebruiken?

Voordat we verder gaan, doen weer eerst even een stapje terug en geven we antwoord op de vraag hoe we Spock kunnen opnemen in ons Maven-project. We nemen allereerst de volgende twee dependencies op (in de <dependencies> tag):

Vervolgens moeten we nog de volgende plugins toevoegen aan de <plugin> tag die weer in de <build> tag terug te vinden is.

Even wat opmerkingen bij de plugins. Binnen BDD, noemen we de test-classes niet XxxTest imaar XxxSpec. We geven zo aan dat classes die eindigen op Spec ook meegenomen moeten worden tijdens het uitvoeren van de tests.

Zoals je in het commentaar ziet, vind ik het niet echt logisch dat er **/*Spec.java moet staan. Groovy-bestanden hebben namelijk de extensie .groovy en niet .java. Maar deze instelling is wel nodig.

Interaction based testing

In onderstaande voorbeeld wordt een KlantenController getest. De KlantenController maakt gebruik van een KlantenService. Als we de KlantenController gaan testen, willen we ons zuiver richten op de correcte werking van de KlantenController.

We weten niet welke implementatie gebruikt zal worden. Daarom willen we alleen maar controleren of de service aangeroepen wordt op de manier die we verwachten. Ook willen we natuurlijk zien dat de KlantenController het antwoord van de KlantenService verwerkt in het resultaat.

De KlantenService is een mock. In het then-stuk zie je dat verwacht wordt dat de methode KlantenService.getKlantOpKlantNummer 1 keer moet worden aangeroepen met de parameter “123” en dan resultaatKlantKlantenService als return value moet geven.

De KlantenService geeft een optional terug. We checken hier direct of de waarde klant inderdaad de door de service teruggegeven waarde van de optional is. Indien de klant niet gevonden is, dan zal de Optional geen waarde hebben. Eigenlijk willen we dit ook testen.

Hierboven testen we het gewenste gedrag als een klant niet bestaat. Ook hier zien we weer de bekende given-, when-, then- en and-blokken. En wordt door de thrown(NietGevondenException) regel gecontroleerd of de controller inderdaad een exception heeft opgegooid.

Aantal aanroepen van een bepaalde methode

De regel 1 * klantenService.getKlantOpKlantNummer(“123”) >> resultaatKlantKlantenService begint met 1 * waarmee we aangeven dat een method 1 keer moet worden aangeroepen. We kunnen hier ook een range gebruiken.

Stel we verwachten dat een methode ergens tussen de 1 en 3 keer wordt aangeroepen, kunnen we dit ook opgeven. (1..3) * klantenService.getKlantOpKlantNummer(_) >> resultaatKlantKlantenService

We hebben het klantnummer nu vervangen door een underscore. We weten namelijk niet met welke parameters getKlantOpKlantNummer wordt aangeroepen.

Valideren parameters bij een methode aanroep

We kunnen de underscore vervangen door _ as String waarbij we aangeven dat we verwachten dat getKlantOpKlantNummer zal worden aangeroepen met een string parameter. Door een predicate te gebruiken kunnen we zelf checks verzinnen waar een parameter aan zal moeten voldoen.

Bijvoorbeeld als we verwachten dat getKlantOpKlantNummer aangeroepen wordt met een klantnummer wat met ‘123’ zal beginnen. (1..3) * klantenService.getKlantOpKlantNummer({it.startsWith(‘123’)}) >> resultaatKlantKlantenService`

Easy does it

Met Spock kunnen we een sterke koppeling maken tussen onze tests en de scenarios die we willen testen (BDD). Het is al met al een krachtig testing framework dat datadriven testing en interaction based testing supereenvoudig maakt.

Tot zover deze eerste kennnismaking. Ik wens je veel succes met Behaviour-Driven Development. En mocht je vastlopen en/of hulp kunnen gebruiken – aarzel niet en neem contact op!