insight 
De afgelopen weken heb ik stilgestaan bij het belang van onderhoudbaarheid van maatwerk applicaties, hoe een Agile ontwikkelaanpak hieraan bijdraagt, hoe de mate van onderhoudbaarheid kan worden gemeten en hoe deze opgebouwde technical debt met refactoring kan worden aangepakt. Deze week sta ik stil bij de rol van testen en geautomatiseerd testen in het bijzonder.
Testbaarheid zorgt voor onderhoudbaarheid
Zoals in het eerste deel besproken, betekent onderhoudbaarheid onder andere testbaarheid en wijzigbaarheid. Vaak zien we dat in de onderhoudsfase van een applicatie de complexe onderdelen niet door iedereen gewijzigd kunnen worden. Bijvoorbeeld dat ontwikkelaars een wijziging niet durven door te voeren, vanwege onvoorziene effecten op de applicatie. Wijzigingen moeten dan vaak door dezelfde personen uitgevoerd worden, waardoor een applicatie aan mensen ‘blijft plakken’. Een onwenselijke situatie. Blijkbaar is de testbaarheid dermate laag, waardoor de wijzigbaarheid in het geding is. Wie brandt z’n handen aan een wijziging die onvoorziene(!) effecten heeft op de werking van een applicatie?rnu003cfigure class=u0022clearfixu0022u003eu003cimg class=u0022aligncenteru0022 src=u0022https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-4-automatiseer-testen-blog-Victor.jpgu0022 srcset=u0022u0022 alt=u0022onderhoudbaarheid-tip-4-automatiseer-testen-blog-victoru0022 width=u0022640u0022 height=u0022autou0022 data-srcset=u0022https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-4-automatiseer-testen-blog-Victor.jpg 160w, https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-4-automatiseer-testen-blog-Victor@2x.jpg 320w, https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-4-automatiseer-testen-blog-Victor@4x.jpg 640wu0022 /u003eu003c/figureu003e
Automatiseer testen
Door vanaf het begin te zorgen voor testbaarheid, wordt de wijzigbaarheid groter. Wanneer je door middel van een test zeker kunt zijn of de gewijzigde functionaliteit blijft werken volgens de specificatie, is de drempel lager voor het maken van de wijziging. Als ontwikkelaar kun je namelijk vertrouwen op de aanwezige testen (let op: niet testernrnu003cstrongu003eru003c/strongu003e). Echter, elke regel code testen is simpelweg te duur en onnodig. Maak een risicoanalyse en focus op de onderdelen die niet triviale business logica bevatten en waar veel schade mee veroorzaakt wordt bij disfunctioneren. Deze analyse voer je uit samen met de business verantwoordelijke(n), door te kijken naar kans en impact. Kennis van teststrategieën helpt tijdens deze exercitie. Voor de hoog-risico-onderdelen moet gelden dat er geen fouten worden aangetroffen in de opgeleverde applicatie. Het ontwikkelteam dient dit als doel te hebben. En door het ontwikkelteam verantwoordelijk te maken voor de kwaliteit en daarmee de testen, worden testen sneller geautomatiseerd. Ontwikkelaars hebben namelijk de neiging repeterend werk te automatiseren, wat leidt tot testscripts. Dit geldt voor alle niveaus: unittesten, integratietesten, ketentesten, performancetesten, penetratietesten, etc. Wanneer je als ontwikkelaar vervolgens kunt vertrouwen op de aanwezige testen, is het doorvoeren van wijzigingen minder risicovol. Onvoorziene *sideu003cstrongu003e u003c/strongu003eeffects** *worden namelijk direct zichtbaar in de testresultaten.
Mutation testing
Toch worden onvoorziene side effects soms helemaal niet opgemerkt door falende testen. De testen gaan goed en toch is de werking incorrect. Hoe zit dat? Er moet niet alleen aandacht zijn of alle (te testen) code wordt afgevangen door testen (u003ca class=u0022clru002du002dprimu0022 href=u0022https://en.wikipedia.org/wiki/Code_coverageu0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003ecode coverageu003c/au003e), maar ook of de testen daadwerkelijk juist zijn. Oftewel: quis custodiet ipsos custodes (wie zal de bewakers zelf bewaken)? * Met u003ca class=u0022clru002du002dprimu0022 href=u0022http://pitest.org/u0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003emutation testingu003c/au003e worden ‘mutanten’ gegenereerd van de code, die ervoor moeten zorgen dat de testen falen. Wanneer de testen niet falen, is een mutant ontdekt die zorgt voor een foutieve werking, zonder de testen te laten falen. Voorbeelden van mutanten zijn het omdraaien van *booleans (true en false), wijzigen van operators (+, -, …) en verwijderen van statements.rnu003cfigure class=u0022clearfixu0022u003eu003c/figureu003ernu003cfigure class=u0022clearfixu0022u003eu003cimg class=u0022aligncenteru0022 src=u0022https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-4-automatiseer-testen-blog-Victor-02.jpgu0022 srcset=u0022u0022 alt=u0022onderhoudbaarheid-tip-4-automatiseer-testen-blog-victor-02u0022 width=u0022512u0022 height=u0022autou0022 data-srcset=u0022https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-4-automatiseer-testen-blog-Victor-02.jpg 256w, https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-4-automatiseer-testen-blog-Victor-02@2x.jpg 512w, https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-4-automatiseer-testen-blog-Victor-02@4x.jpg 1024wu0022 /u003eu003c/figureu003e
Up-to-date specificaties en ATDD
Uitdaging bij het opzetten van testen zijn de specificaties. Testen worden vaak opgezet op basis van de specificaties, waarbij het uitgangspunt is dat deze kloppend zijn met de daadwerkelijk gebouwde functionaliteit. Naar mate een applicatie verder in de levensfase zit, zien we dat het lastig is dit vol te houden. Specificaties gaan afwijken (doordat deze bijvoorbeeld niet consequent zijn bijgewerkt), waardoor discussie ontstaat over de juiste werking. De laatste jaren zien we steeds vaker dat specificaties in de vorm van een testscenario worden opgesteld. We noemen ditrnrnu003ca class=u0022clru002du002dprimu0022 href=u0022https://en.wikipedia.org/wiki/Acceptance_test%E2%80%93driven_developmentu0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003eu003cemu003eAcceptance Test Driven Developmentu003c/emu003e u003c/au003e(ATDD). Door specificaties op deze manier op te stellen, kan geen verschil ontstaan tussen de specificaties, de testscripts en daarmee de functionele werking van de applicatie. Over het algemeen wordt dit formaat gebruikt:rnu003cp style=u0022padding-left: 60px;u0022u003eu003cstrongu003eGivenu003c/strongu003eu003cstrongu003e u003c/strongu003eu003cstrongu003e(setup) u003c/strongu003e A specified state of a system u003cstrongu003eWhenu003c/strongu003eu003cstrongu003e u003c/strongu003eu003cstrongu003e(trigger) u003c/strongu003e An action or event occurs u003cstrongu003eThenu003c/strongu003eu003cstrongu003e u003c/strongu003eu003cstrongu003e(u003c/strongu003eu003cstrongu003everificationu003c/strongu003eu003cstrongu003e) u003c/strongu003e The state of the system has changed or an output has been producedu003c/pu003ernDit formaat zorgt ervoor dat ook business verantwoordelijken in staat zijn de scenario’s te lezen, te begrijpen en na wat oefening op te stellen. Dit beperkt het risico op misinterpretatie, een ander bekend fenomeen binnen software development.
Cucumber
Tools als u003ca class=u0022clru002du002dprimu0022 href=u0022https://cucumber.io/u0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003eCucumber u003c/au003een u003ca class=u0022clru002du002dprimu0022 href=u0022http://www.specflow.org/u0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003eSpecFlow u003c/au003emaken het mogelijk dit soort scripts te automatiseren waardoor ze uitvoerbaar worden. Hiermee is het gat tussen specificaties, testen en daadwerkelijke code gedicht. En testbare code is onderhoudbare code! Naast geautomatiseerd testen is exploratory testen een manier om vast te stellen of de applicatie correct functioneert onder menselijk gebruik. Mensen zijn creatief in het gebruik van software. Creatiever dan testscripts kunnen afdekken. Het gaat hier dan ook niet om u003cemu003ecode coverageu003c/emu003e, maar logisch (menselijk) gedrag. Crowd testen is hier een goed voorbeeld van. Stel de applicatie beschikbaar aan een grote groep testers en betaal ze voor bevindingen in plaats van de geleverde inspanning. Volgende week aandacht voor de infrastructuur. Tot op heden focussen we ons op het maken van code. Onderhoudbaarheid beperkt zich niet tot de code en wordt ook bepaald door de infrastructuur waar de applicatie op draait.