TestAutomatisering & PerformanceTesten

Testen? Begin bij de basis! | Het belang van unittesten

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?

  1. Het zorgt voor een veiligheidsnet – we weten dat de code werkt
  2. Reduceert kosten en technisch tekort
  3. Unittesten fungeren als regressietesten en vormt de basis voor testautomatisering
  4. Creëert betere design patterns
  5. Focus op het werk dat echt af moet – Definition of Done
  6. Onderhoud – het wordt niet moeilijker om te onderhouden zodra je codebase groter wordt
  7. Feedback-loop voor validatie code wijzigingen
  8. 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!

 

Dit bericht is geplaatst in Testautomatisering en getagd in Testautomatisering Unittesten

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Nieuws

Blijf op de hoogte

PerformanceArchitecten @The Next Web conferentie

04/07/2018

Was het een interessante conferentie? Beslist. Heeft TNW PerformanceArchitecten op nieuwe ideeën gebracht? Zeker. Heb jij TNW gemist, maar wil je je wel in vijf minuten op de hoogte laten brengen? Lees dan snel verder! En mocht je er wel zijn geweest.. We zijn benieuwd naar jouw beeld! Wat is de Next Web? Voor hen […]

De ‘waar begin ik met testautomatisering’ handleiding.

11/04/2018

Wij worden regelmatig gevraagd te helpen bij het opzetten of verbeteren van testautomatisering in een Agile omgeving bij een klant. En hoeveel ervaring je ook hebt, wat je opdracht ook precies inhoudt en in welk team je ook terechtkomt, het is altijd even zoeken waar te beginnen. Onderstaand stappenplan ondersteunt hierbij. PerformanceArchitecten organiseert veel kennissessies. Zo […]

Wat is het Bug Filter?

26/03/2018

Een algemeen gedeelde opvatting over het doel van testen binnen software ontwikkeling is “het tegenhouden van bugs en het afdekken van risico’s”. Over hoe dit vervolgens het best valt te organiseren, bestaan er echter vaak veel meningsverschillen. In deze 2 minute snack sta ik graag even stil bij een inzicht dat verhelderend werkt in deze […]

Testen? Begin bij de basis! | Het belang van unittesten

19/02/2018

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 […]

De Absolute Beginners Guide voor API Testen met rest-assured.io

16/01/2018

Omdat het moeilijk was om een eenvoudige tutorial te vinden voor rest-assured.io, ben ik na eerst zelf uit te vinden hoe het werkt, maar eens begonnen met een tutorial die de absolute basics uitlegt over rest-assured. In deze post laat ik zien hoe we op een zo eenvoudig mogelijke manier een API test kunnen maken met […]

APACHE MPM (op *nix servers)

07/11/2017

Benieuwd naar de impact van het wijzigen van Apache MPM Prefork naar Worker? Lees dan door! Bij één van onze klanten heb ik dit onderzocht. Omdat dit ook interessant kan zijn voor anderen, deel ik mijn resultaten en ervaringen graag. Het is misschien wat technisch allemaal, maar voor performancetesters, de doelgroep, is het vast goed […]

Performancetesten en CI/CD, gaat dat samen?

13/10/2017

De afgelopen najaarseditie van Testnet stond onder het thema Continuous Everything vooral stil bij CI/CD en natuurlijk testen. Gezien DevOps en CI/CD ook grote invloed hebben op het vakgebied performance (testen), zijn wij blij dat we vanuit PerformanceArchitecten een bijdrage mochten leveren door middel van het delen van onze visie hierop. Onze collega René Meijboom […]

Een eerste indruk van Gauge

08/09/2017

Tijdens één van onze kennismiddagen hebben we gekeken naar het testtool Gauge. Doel van de sessie was om een beeld te krijgen wat de toegevoegde waarde van Gauge is voor een tester. Benieuwd naar onze ervaringen? Lees dan snel verder! Gauge is een open source project, gesponsord door ThoughtWorks en belooft in het kort het […]

Test Automation Framework BDD

16/06/2017

De afgelopen tijd heb ik in een opdracht collega’s mogen adviseren over de positieve impact van het Test Automation Framework BDD rondom het thema Agile. In een vorige blog ‘Transformation’ is te lezen wat BDD voor mij betekent en hoe BDD voor synergie zorgt tussen verschillende disciplines binnen Agile-teams met als doel het leveren van kwalitatief hoogwaardig […]

Creëer meer eenheid in je SpecFlow steps met Step Argument Transformations

11/04/2017

Laatst kreeg ik de vraag, “Hoe maak je in je testdata onderscheid tussen een regular expression en een gewone tekst”. Oftewel: Hoe beheer je verschillende soorten steps als ze alleen verschillen in de manier waarop data vergeleken wordt. Je hebt een veld en je wilt controleren of er een bepaalde waarde in staat, maar soms […]

SSL/TLS versie en cipher in HP LoadRunner

29/03/2017

In deze blog wil ik even stilstaan bij de resultaten van een performance test die niet overeenkwamen met de verwachtingen die wij als team hadden. Een aantal transacties gingen in responstijd omhoog en het CPU gebruik nam flink toe. Omdat het ons veel tijd heeft gekost, deel ik dit graag met jullie zodat wij performance […]

Regular Expressions en Testautomatisering, twee problemen of juist een oplossing?

25/03/2017

Bij geautomatiseerde checks wil je regelmatig een verwachte waarde controleren tegen een actuele waarde. Vroeg of laat kom je dan in aanraking met wildcards: Je wilt bijvoorbeeld weten of de tekst “Er zijn 42 resultaten gevonden” voorkomt, maar het aantal, hier 42, kan variabel zijn. Van 42 wil je dan een wildcard maken. De meest […]