Met de opkomst van Agile wordt steeds vaker voor een Continuous Integration (CI) setup gekozen, waarbij met continuous integration testen geautomatiseerd ingezet worden als onderdeel van de build. Nu is dit niet nieuw. Unit testen zijn al een ruime tijd onderdeel van de build. Echter door het teamdynamiek welke Agile met zich mee bracht, proberen functioneel testers en test automatiseerders bij het gedachte goed van CI aan te haken. De keuze is al snel gemaakt. De geautomatiseerde acceptatie testen, welke vaak via de GUI verlopen, moeten meedraaien in de CI build, die bij elke code wijziging gaat draaien. In deze blog onderbouw ik waarom dit een bad practice is.
Best practices voor Continuous Integration testen
- Een zelf testende build
- Zorg dat de build snel is
Daarnaast wil ik nog een derde best practice toevoegen namelijk dat CI moet zorgen voor een betrouwbare uitkomst van de build. De build is of gefaald of geslaagd en als deze faalt moet er een duidelijke en reproduceerbare reden voor zijn.
Als we kijken naar geautomatiseerde testen welke via de GUI plaatsvinden, ondervinden we daar een aantal standaard problemen mee welke we al jaar en dag kennen, namelijk, geautomatiseerde testen…
- … zijn traag in de uitvoer;
- … opereren end-2-end in de applicatie, van GUI t/m database en vise versa. Ze vertrouwen op een vaste set aan test-data welke niet mag veranderen.
- … hebben last van timing issues of elementen wel of niet verschijnen;
- … bij verandering van de GUI moeten de testen aangepast worden;
- … kosten relatief veel tijd om te maken en kosten veel onderhoud. Vergeet niet, test code is ook code en deze moet onderhoudbaar zijn;
Samengevat, geautomatiseerde GUI testen zijn, zoals we dat noemen, ‘brittle’. Het kost veel effort om ze te maken en ze zijn erg kwetsbaar. De build zal door deze kwetsbaarheden vaak falen waarbij een test de veroorzaker is en niet de programmatuur onder test door regressie. Indien het aantal geautomatiseerde acceptatie testen via de GUI toeneemt zal dit zorgen voor een lang lopende build waarbij feedback steeds minder snel gegeven kan worden.
Beide zullen leiden tot acceptatie, acceptatie dat de build (te) lang duurt én vaak een verkeerde uitkomst geeft waardoor test automatisering minder toegevoegde waarde biedt. Kortom: een bad practice.
Oplossingen
Ik ga niet zeggen dat geautomatiseerde GUI testen slecht zijn. Ze zijn in bepaalde gevallen erg goed namelijk dat ze de applicatie in elke laag raken. In dit opzichte zijn en blijven het waardevolle testen. Ik zeg alleen wel dat je ze niet mee moet nemen in je standaard CI build. Je kan ze prima mee laten lopen in bijvoorbeeld een nightly build.
Als je GUI testen opzet maak dan niet gebruik van record and playback tools maar maak gebruik van zogenaamde page object patterns waardoor herbruikbaarheid én onderhoud een stuk beter geborgd wordt.
Daarnaast, introduceer in het team, de zogenaamde test automation piramide welke in 2009 beschreven is door Mike Cohn. Hierdoor ontstaan er meer unit- en integratietesten. De integratie testen zijn prima om bijvoorbeeld business rules geautomatiseerd te verifiëren waardoor er veel minder geautomatiseerde GUI testen nodig zijn.
