Skip to content

Blog

The tests don't lie

Als testen falen dan is een veelgehoorde reactie: " dit komt niet door de laatste code wijziging, de test zal wel fout zijn". Dit wordt vaak veroorzaakt doordat testen onbetrouwbaar zijn. Deze testen worden aangeduid als flaky (willekeurig falen/slagen van testen) of false-positives. Een test is false-positive als deze moet falen maar blijft slagen. In een CI/CD pipeline waarbij releases geautomatiseerd doorrollen naar een volgende stage is het het belangrijk dat deze niet vertraagd worden door testen welke onterecht falen. Het uitzoeken ervan kost onnodig tijd en het principe van CI/CCD wordt onderuit gehaald, omdat er handmatig ingrijpen noodzakelijk is.

Ben je benieuwd hoe je testen ontwikkelt die altijd slagen en falen als het moet? Lees dan vooral de rest van deze blog!

 

Een goede test is meer dan enkel het laten slagen van de test

 

Code welke wordt geschreven voor het bouwen van een applicatie moet voldoen aan 'code-patterns' en 'quality checks'. In een code review, zoals een pull-request wordt de geschreven code getoetst aan de geldende code-patterns.

Quality checks worden veelal geautomatiseerd uitgevoerd middels linting-tools als ESLint of SonarCloud voor het uitvoeren van de statische code analyse om ‘code smells’ te identificeren.

Deze checks worden vóór de unit-testen uitgevoerd. Dit gebeurt in een vroeg stadium zodat vertrouwen wordt opgebouwd en de focus gelegd kan worden op het ontwikkelen van business logica. 

Voor het ontwikkelen van testen geldt precies hetzelfde. De kwaliteit van de test-code kan worden geborgd door het toepassen van dezelfde checks en patterns. 

Code geschreven om testen te automatiseren dienen van eenzelfde niveau te zijn als de code voor de applicatie. Alleen het laten slagen van een test toont niet de kwaliteit van de test ansich aan.



Design patterns

De mate van onderhoudbaarheid van testen wordt bepaald door de herbruikbaarheid, leesbaarheid, wijzigbaarheid van de code. Dit implementeren klinkt makkelijker dan het is. Het is nog moeilijker als testen worden geschreven op verschillende niveaus zoals integratie en E2E testen.

Om dit te bewerkstelligen kan gebruik gemaakt worden van ontwerp patronen welke ook binnen softwareontwikkeling worden toegepast, zogenoemde 'design patterns'. 

Denk als voorbeeld aan een webshop met producten en productvarianten. Het aanmaken van testdata bestaat uit het aanmaken van diverse objecten (producten en productvarianten).  Testdata is vaak sturend voor het gedrag van de applicatie. Zoals het wel of niet tonen van een checkbox, extra wizardstep etc. Testen worden hierdoor 'vervuilt' met 'if-else' statements om de testdata in diverse varianten aan te maken. 

De logica kan worden geabstraheerd door toepassen van het 'factory design pattern'. De 'factory' bevat alle logica om de testdata in allerlei varianten aan te maken. In de test is er nog maar één methode die de 'factory' aanroept. De 'factory’ retourneert de data welke de test nodig nodig heeft en meer niet. 

Testen worden hierdoor erg overzichtelijk en zijn makkelijk te begrijpen voor iedereen. Wijzigt de opzet van producten of productvarianten, dan dient alleen de 'factory' aangepast te worden i.p.v.de logica welke in alle teste gedefinieerd staan. Tel uit je winst!

 

Identificeer de rotte appels

Ondanks een gedegen testopzet kunnen testen nog steeds falen binnen een CI/CD pipeline. Goede reporting geeft niet alleen het inzicht in welke testen falen, maar het beantwoordt ook de waarom-vraag.  Onder andere door falende testen te voorzien van logging,  screenshots en screen recordings .

Naast falende testen kenmerkt goede reporting zich door inzicht te geven in trends en en de doorlooptijd van testen. Met trends kunnen ‘flaky’ testen gedetecteerd worden. Dit zijn testen welke in meerdere release falen afgewisseld met releases waarin deze slagen.

Deze’ rotte appels’ moeten geïdentificeerd en opgelost worden. 

Reporting verschaft daarnaast inzicht in de doorlooptijd van de testen. Hiermee kunnen  trage testen geïdentificeerd worden. Belangrijk om te onderzoeken waarom deze testen traag zijn. Is de verkeerde opzet gekozen, fout in de applicatie of een andere aantoonbare reden.

Reporting helpt voor het opzetten van betrouwbare testset en tegelijkertijd draagt het zorg voor een testset welke snel feedback levert.

 

Testen zijn nooit af

Na het opzetten van een goede testen en het identificeren van de testen welke flaky of traag zijn is het werk nog niet klaar. De testen moeten ‘levend’ gehouden worden.

Continu moet er net als de applicatie-code onderhoud op plaatsvinden. Denk hierbij aan het updaten van packages, testen herschrijven naar de veranderende werkelijkheid en blijven tweaken om testen nog sneller en robuuster te maken.  

Het allerbelangrijkste van goed onderhoud is het verwijderen van testen. Als de software gedurende tijd groeit zullen er ook steeds meer testen bij komen. Het kenmerk van testen is dat deze snel feedback geven over de de kwaliteit van de software. Worden er alleen maar testen toegevoegd, dan zal feedback steeds langer op zich laten wachten.

Challenge jezelf, het team en de stakeholders continu met de vraag: “hoe erg is het in productie als deze test zou falen?”. Is het antwoord dat de test weinig impact heeft? Verwijder dan de test.

 

100% vertrouwen!

De basis van betrouwbare testen is de opzet. Net als de applicatie-code dienen de testen opgebouwd te worden aan de hand van software-architectuur. Goede architectuur en de checks om code-kwaliteit te borgen is het begin.

Daarnaast is goede reporting de sleutel tot succes. Met reporting kunnen de falende testen vaak snel omgeturnd worden naar stabiele slagende testen. Gedegen reporting maakt afwijkingen in doorlooptijd en/of slaag-ratio inzichtelijk. Afwijkingen duiden vaak op flaky testen of testen met een foutieve opzet.

Hoe robuust de testen ook zijn, het blijft uiteindelijk een samenspel van meerdere factoren om testen in de CI/CD pipeline te laten slagen. Echter testen moet zoveel vertrouwen geven aan het team, zodat er gezegd gaat worden: “de testen falen, er zal wel een fout in de software zijn“.