Specificeren versus verifiëren

Unittesten is iets wat we inmiddels allemaal kennen. In een methode als Test Driven Development hebben we zelfs het doel om eerst de testen te specificeren en daarna de code (het gedrag) te implementeren. Dat klinkt goed en werkt ook goed als de applicatie architectuur het ondersteund. Dat we binnen Sogyo volgens een domein gedreven architectuur werken is inmiddels wel bekend en daar past deze stijl ook erg goed bij.

Op dit moment is er een interessante ontwikkeling gaande die vooral in de Ruby-wereld al uitgebreid toegepast wordt en met groot succes. Het gaat om specificatietalen. In zijn artikel A new look at Test Driven Development beschrijft Dave Atels op een beeldige manier wat het verschil is tussen de specificatietalen en testgedrevenheid. In essentie komt het neer op vooraf specificeren versus het achteraf verifiëren. Dan zou je kunnen zeggen “lekker spannend”. Echter wat het wat mij betreft interessant maakt is het feit dat je met specificatietalen dus vooraf formeel kunt beschrijven waaraan de implementatie moet voldoen. Je specifieert dus in een executeerbare taal. (Puur technisch gezien gelijkwaardig aan Unittest technieken). Dat zegt natuurlijk ook iets over de (lage) abstractie waarin de specificatie plaatsvindt. Die zou in dit geval op scenario niveau binnen een Use Case moeten liggen om concreet genoeg te zijn. Dat is mooi!
We hebben recent voor een klant een platform gerealiseerd waarin de ontkoppeling van het domein met de presentatie services plaatsvindt door “contracten” (of views op het domein) op Use Case niveau te definiëren. Dat betekent dus dat je een specificatietaal in moet kunnen zetten om tests voor deze contracten vooraf te schrijven. Interessant terein om verder te ontdekken.

Overigens zijn er best veel ontwikkelingen op gebied van specificatietalen. RSpec is in de Ruby-wereld een heel bekende. JBehave en NBehave lijken goede alternatieven voor Java en .NET. Maar ook Microsoft zelf is druk bezig met een implementatie. Je moet er nog even voor op zoek binnen Microsoft Research, maar Spec# klinkt veelbelovend.