Test-driven development: specificatiedocumenten en unit tests

In dit artikel gaan we dieper in op de ontwikkeling van de risico-inspecties van de nieuwe Risk Finder. We leggen uit hoe we risico’s classificeren en hoe we de kwaliteit en snelheid van de software waarborgen.

De nieuwe Risk Finder herkent steeds meer risico’s in Excel. De resultaten van deze ‘risico-inspecties’ worden op basis van risiconiveau, risicocategorie en met een voorstel voor actie of een oplossing aan de eindgebruiker gepresenteerd. Ieder risico wordt duidelijk beschreven en, waar mogelijk, ook visueel toegelicht. Bovendien verwijst de Risk Finder met een link terug naar de locatie van het gevonden probleem in het Excel bestand, zodat het probleem direct verholpen kan worden.

Specificatiedocumenten

Voor ieder risico dat we kunnen herkennen in Excel bouwen we een specificatiedocument. Dat is een (hoe kan het ook anders) Excel bestand waarin we alle mogelijke verschijningsvormen van dat specifieke probleem opnemen. Voor iedere instantie bepalen we of het een direct risico vormt, of het slechts een zwakte van het model betreft of dat we het enkel willen benoemen als observatie, waarvan de impact onbekend is.

Voordat we beginnen met programmeren discussiëren we als team uitvoerig over wanneer een inspectie wel of niet moet triggeren en hoe groot het risico werkelijk is. Dit doen we op basis van de vele praktijkvoorbeelden en ervaring die we in de loop der jaren hebben opgedaan. Door alle perspectieven op een risico uitvoerig te bespreken komen we achteraf zelden tot nieuwe inzichten en hoeven we geschreven code later bijna nooit te herzien.

Test-driven Development

Zodra we de classificering van de verschillende verschijningsvormen van een risico volledig hebben vastgelegd ontwikkelen we unit-tests. Unit-tests zijn stukjes code die vertellen wat de uitkomst van een bepaalde inspectie moet zijn. Als wij op een specificatiedocument bijvoorbeeld 23 voorbeelden hebben verwerkt van hardcoded numbers, dan maken we ook 23 unit-tests. Zo kunnen we per geval controleren of de code die we schrijven doet wat we bedacht hebben.

Een unit-test controleert één onderdeel (unit) van het programma. Door alle onderdelen los te controleren kun je je tijdens de ontwikkeling richten op specifieke functionaliteiten en weet je precies wat er stuk is als er iets misgaat. Momenteel hebben we ongeveer 600 unit-tests voor alle inspecties die de Risk Eliminator en de Risk Finder uitvoeren. Zo kunnen we met één druk op de knop zien of alle inspecties nog de gewenste resultaten geven als we iets gewijzigd hebben.

Unit-tests maken het programmeren leuk

Wanneer we beginnen met de daadwerkelijke implementatie, dus als we het programma gaan leren om het betreffende probleem te gaan herkennen in Excel, dan geven alle unit-tests in eerste instantie verkeerde uitkomsten. Alle vinkjes staan op rood, omdat de code nog niet voldoet; het probleem wordt nog niet herkend. En iedere keer als je een stukje ‘de goede kant op programmeert’, dan springen er een aantal vinkjes van rood naar groen. Zodra alles op groen staat, dan is de code gereed voor gebruik; dan zijn de resultaten precies zoals we ze vooraf bedacht hebben.

Voordelen van Unit-tests

Als we iets veranderen in de code, dan zien we het, zoals gezegd, direct als een van de vinkjes weer op rood springt. We weten dan direct waar het probleem zit en daardoor kunnen we het snel en efficiënt repareren. Dat is een groot voordeel aan werken met unit-tests.

Unit-tests maken het ook makkelijker om de snelheid van de software te verbeteren. We willen niet dat onze klanten lang op een analyse moeten wachten en daarom besteden wij veel tijd aan het optimaliseren van de performance. Naarmate we meer inspecties implementeren, ontstaan er ook meer opties voor optimalisatie. Daarom nemen we regelmatig stukken code onder de loep om te kijken of er verbeteringen mogelijk zijn. Dan herschrijven we dat stuk op een manier dat de uitkomst hetzelfde blijft, maar het rekenproces sneller wordt. Soms gooi je daardoor een hele ingewikkelde implementatie op de schop en het kost heel wat hersencapaciteit om te bedenken of het theoretisch dezelfde uitkomsten zal geven. Dankzij de unit-tests kunnen we de wijzigingen binnen een mum van tijd valideren; dan geven alle unit-tests een groen vinkje terug.

Beperkingen van Unit-tests

Deze vorm van test-driven development is tegenwoordig een vrij standaard aanpak bij softwareontwikkeling, maar het heeft wel beperkingen. We testen hiermee vooral de werking ‘onder de motorkap’: de krachtige spreadsheetanalyses. Maar de zogeheten ‘front-end’ (de knopjes, de kleurtjes en plaatjes) is niet opgenomen in unit-tests. Terwijl we er natuurlijk wel steeds zorg voor moeten dragen dat iets wat ‘aan de achterkant’ goed gaat, ook ‘aan de voorkant’ een logisch en leesbaar resultaat geeft. Dat is echter een veel minder exact proces, omdat de front-end vormgeving betreft. Voordat we een nieuwe versie uitbrengen doen we eerst altijd een test-sprint; twee volle weken waarin we ons volledig focussen op het testen van de front-end. Met andere woorden: geeft de tool het probleem werkelijk weer, zou ik snappen wat hier staat als ik de tool nog niet kende, of als ik niet bekend was met dit Excel model, kan ik op een formule klikken en word ik dan direct naar Excel geleid; dat doen we allemaal handmatig.

Zie alle blog-artikelen