Inleiding
Mijn vrouw en ik zijn op dit moment bezig met het bouwen van een huis. In dit geval niet als bouwvakker of aannemer, maar dan toch wel als opdrachtgever. Spannend vinden we het zeker, leuk ook. Wat heeft dit te maken met unittesten zou je denken. Nou, het volgende…
Het huis wordt namelijk gebouwd met betonelementen die onder geconditioneerde omstandigheden gefabriceerd en getest zijn om vervolgens kant-en-klaar op de bouwplaats aan te voeren. Daar worden ze met behulp van speciale verbindingen aan elkaar gekoppeld, die er samen met de fundering voor gaan zorgen dat het een stevig en robuust huis gaat worden. De logische indeling hebben we op tekening staan waar we nog jaren plezier van gaan hebben. Het gaat dus nog mooi worden ook! Het vergelijk met softwareontwikkeling is snel gemaakt. De code vormt samen met de architectuur de basis van de applicatie. Die basis is natuurlijk altijd al belangrijk, maar binnen Agile wordt dit nog meer benadrukt.
Door de opkomst van Agile softwareontwikkeling heeft unittesten enorme stappen gemaakt.
Unittesten vormen een solide basis voor testautomatisering en representeren het grootste onderdeel van de testpiramide van Mike Cohn. Als test (automation) consultant ben ik van mening dat unittesten voor een lager risicoprofiel zorgen bij aanpassingen van je sourcecode en onbedoelde fouten introduceren, hetgeen de kwaliteit van een applicatie ten goede komt. Als ICT-organisatie bespaar je ook simpelweg tijd en geld! Kwaliteit, tijd- en geldbesparing: wie wil dit nou niet?
In deze blog wil ik het hebben over de urgentie van unittesten voor zowel de ICT-organisatie als het ontwikkelteam.
De definitie van een unittest die ik voor deze blog hanteer: een geautomatiseerd stuk code dat een onderdeel (unit) van een geschreven software aanroept en valideert of het gedrag van dit onderdeel (unit) doet wat het zou moeten doen. Idealiter test je hiermee een klasse of een methode. Als ontwikkelmethode wordt hierbij vaak Test-Driven Development (TDD) gebruikt, waarbij eerst de testen worden geschreven en vervolgens de implementatie van de code. Let wel op dat de applicatie nog steeds fouten kan bevatten terwijl alle unittesten in orde zijn.
Het valt me regelmatig op dat de testcases zich vaak beperken tot integratietesten of zelfs enkel tot (geautomatiseerde) functionele testen en in het ergste geval alleen maar tot manuele testen. Dat laatste is echt vragen om serieuze problemen. Zeker wanneer je als ontwikkelteam dagelijks wil uitrollen zijn unittesten onmisbaar. Ze vormen een integraal onderdeel van de Continous Integration – Continous Deployment (CI/CD) Pijplijn. Hoe komt het dan dat TDD of het altijd schrijven van unittesten nog niet vanzelfsprekend is?
Hieronder tref je een aantal persoonlijk ervaren tegenwerpingen: 1 – Het kost te veel tijd om unittesten te schrijven
Hoeveel tijd en geld kost het de ICT-organisatie vandaag doordat het continu nodig is om te refactoren, te debuggen en om oplossingen voor nieuw geïntroduceerde bugs te vinden? De grootse toegevoegde waarde is niet alleen het voorkomen van productie bugs, maar grotendeels het verkrijgen van “vertrouwen” in het systeem. Bijvoorbeeld het maken van een wijziging in het systeem kan consequenties met zich meebrengen, omdat de kans bestaat dat een ontwikkelaar andere onderdelen van de code kapot maakt. Daarnaast eindigt de ontwikkelaar met een terughoudend gedrag bij de eerstvolgende wijziging die uitgevoerd zou moeten worden op verzoek van de business. Waarom? Het vertrouwen in de applicatie is minder.
Als programmeur wil je dan ook niet snel refactoren zolang je de impact hiervan niet makkelijk op de rest van de applicatie kan inschatten. Juist onder andere hierom geven unittesten je bij het refactoren van de code meer vertrouwen en ondersteuning.
Kortom: aan het begin van het project kost het schrijven van unittesten inderdaad wat tijd, maar daartegenover krijg je ook meer kwaliteit in je software voor terug en minder bugs op je (scrum)bord. Na paar maanden geïnvesteerd te hebben in unittesten levert softwareontwikkeling je zelf tijdswinst op.
2 – Het duurt te lang om alle testen uit te voeren
In dit geval zou ik adviseren om je testen te refactoren of alleen de meest cruciale testen uit te voeren. Een product risicoanalyse (PRA) kan hierbij helpen waarbij de diepgang van de testen is afgestemd op de risico’s.
3 – Onze legacy code is onmogelijk om te testen
Als ik dit hoor dan denk ik vaak aan het verhaal van de kip en het ei. Stop hiermee! Dit heeft niks met TDD te maken, maar de legacy code zelf. Bijt door de zure appel heen en begin zo snel mogelijk met het introduceren van de unittesten in je project.
4 – Mijn werk is het schrijven van code en geen unittesten
Vaak hoor ik “excuses” van programmeurs “we hebben geen tijd” of “unittesten hebben geen toegevoegde waarde” in softwareontwikkeling. Het werk van jou en de rest van het team is het leveren van “business value” in de vorm van werkende software.
Natuurlijk is het doel van programmeurs om kwalitatieve code te schrijven. Echter, zolang er geen unittesten zijn ben ik van mening dat de code niet voldoet aan kwaliteit. Een softwareapplicatie zonder unittesten is voor mij een huis zonder fundering. Als je een huis bouwt, begin je ook met een gedegen fundering. Daarnaast is de kans aanwezig dat bij het oplossen van een bug nieuwe bugs geïntroduceerd kunnen worden die uit de aandacht van de programmeur en/of tester zijn ontsnapt. Een unittest dient in een dergelijk geval als een preventieve maatregel om deze risico af te dekken en de grip op kwaliteit te vergroten.
Dus, wat is de toegevoegde waarde van unittesten?
Het zorgt voor een veiligheidsnet – we weten dat de code werkt
Reduceert kosten en technisch tekort
Unittesten fungeren als regressietesten en vormt de basis voor testautomatisering
Creëert betere design patterns
Focus op het werk dat echt af moet – Definition of Done
Onderhoud – het wordt niet moeilijker om te onderhouden zodra je codebase groter wordt
Feedback-loop voor validatie code wijzigingen
Documentatie
Persoonlijk vind ik unittesten prachtig, omdat deze concrete informatie geven aan programmeurs/technische testers waar een onvolkomenheid zich bevindt, bijvoorbeeld op lijn 366 in je sourcecode. Het idee dat testen van units voor het ontwikkelen van softwareapplicatie de kosten doet afnemen en de veronderstelling dat het zo snel mogelijk oplossen van een bug geld bespaart licht ik graag toe met behulp van de onderstaande grafiek. In grafiek 1 is een groene en rode lijn te zien welke de totale kosten over de ontwikkeltijd van twee softwareapplicaties representeert.
Grafiek 1 – De totale kosten bij het wijzigen van code
De applicatie met rode lijn “Code zonder unittesten” begint met een lagere uitgave dan de applicatie met groene lijn “Code met unittesten”. Het is niet verrassend dat de applicatie zonder unittesten na verloop van tijd meer geld kost, vanwege refactoren, debuggen, ondersteuning teamleden, bugs oplossen, opnieuw releasen etc. Volgens deze beoordeling met betrekking tot kostenbesparing kunnen ICT-organisaties zelf de break-even punt berekenen waarin het testen van units terugbetalen. Na verloop van tijd kun je zelfs de totale besparingen zien helemaal rechts van de grafiek tussen de rode en groene lijn bij het schrijven van unittesten.
Daarnaast brengt het wijzigen van willekeurige functionaliteiten of componenten van een applicatie meer risico’s met zich mee bij “Code zonder unittesten”. In grafiek 2 is de uitvoering te zien van “Code met unittesten” met veel minder risico en meer kwaliteit in je software.
Grafiek 2 – De risico’s bij het wijzigen van code
Softwareontwikkeling is een teamverantwoordelijkheid. Doordat in teams samengewerkt wordt met verschillende achtergronden is iedereen in dit multidisciplinaire team gedwongen om mee te denken en mee te doen met testen. Organisaties zijn steeds meer waarde gedreven en iedereen in het team werkt mee om waarde te leveren. Deze verbreding leidt tot nieuwe kansen voor testers om eerder betrokken te raken bij nieuwe ontwikkelingen (shift left), die bijvoorbeeld hun teamleden kunnen ondersteunen/coachen bij het testen.
Zo heb ik tijdens mijn laatste opdracht programmeurs geholpen bij het aanvullen en reviewen van unittesten. Daarnaast heb ik zelf geautomatiseerde functionele testen geschreven met als resultaat een hoger dekkingspercentage in de software.
Conclusie
Unittesten zijn onmisbaar en vormen een belangrijke schakel in het Agile software ontwikkelproces. De unittesten zorgen niet alleen voor kwalitatief beter software, maar ook het vertrouwen in het ontwikkelteam groeit en bespaart de ICT-organisatie op lange termijn tijd en dus inspanning en geld. Zijn de bovenstaande stellingen jou ook bekend en vind jij dat het echt anders moet, schroom niet om contact met PerformanceArchitecten op te nemen. Ook als je het niet mee eens bent met de stellingen komen we graag met je in contact. Wij van PerformanceArchitecten geloven namelijk heilig in testautomatisering en hebben een uitgesproken visie op ons vakgebied. Samen inspireren en bouwen aan de toekomst!
Comments