Bloeiperiode voor volautomatische end-to-end tests
In het verleden waren end-to-end (E2E) tests vaak te duur om op te zetten en braken ze snel, waardoor ze onderhoudsintensief waren. Met de opkomst van AI kun je tegen redelijke kosten een stabiele E2E suite opbouwen.
Het is de droom van menig product owner, een uitgebreide test suite - de zogenaamde end-to-end, oftwel E2E, tests – waarbij je na iedere oplevering volautomatisch al je use cases kunt doorlopen om te kijken of je product nog werkt, dit om regressie te voorkomen. Dit kon al enige tijd. Het probleem is altijd geweest dat de investering om te komen tot een dergelijke test suite hoog was, terwijl de kosten om de suite in stand te houden navenant zijn.
In de praktijk zie je dan ook niet zelden dat gekozen wordt voor bijvoorbeeld een handmatig uitgevoerde regressietest of een test suite die alleen maar de meest urgente use cases afdekt, een subset van het totaal.
De verandering: coding agents
Twee aspecten van coding agents maken dat E2E tests met een comeback bezig zijn:
- coding agents hebben guardrails nodig
- coding agents verlagen de kosten voor het bouwen en onderhouden van een E2E suite aanzienlijk
Als een coding agent met je instructies aan de slag gaat, dan moet het ingekaderd worden met een helder doel en gefaseerd plan. De coding agent zal fouten maken, dat is een feit. De vraag is of de coding agent daarvan kan herstellen. De guardrails helpen de coding agent daarin, geven als het ware bounce-back, zoals Rocky Bilbao die uit de touwen klimt en een comeback maakt na een paar rake klappen te hebben geïncasseerd. Een E2E test suite zorgt dat de coding agent het eigen werk kan testen, de resultaten kan analyseren en het plan bijstellen om te herstellen van een foute koers.
Coding agents kunnen je goed ondersteunen om hun eigen guardrails te schrijven. Je moet je werkproces daar wel op inrichten en je E2E testsuite behandelen als een first class citizen in je codebase. Het krijgt dus net zoveel aandacht, energie en kwaliteitsdrive als de productie-code dat krijgt.
Werkproces voor een E2E test suite
Het reguliere werk voor een applicatie bestaat eruit om functies in te bouwen. Die worden geformuleerd in werkpakketten, bijvoorbeeld change requests.
Use cases. De eerste uitdaging is om die change requests op de juiste wijze in formele use cases te vangen. Nadat een werkpakket is afgerond, laat je de coding agent scannen op je commits en de beschrijvingen van de werkpakketten. Het kan ook vooraf, maar de kans dat er nog veranderingen van inzicht zijn, is altijd aanwezig en die wil je ook meepakken. Use cases zijn snel geschreven en storen minimaal je werkproces.
Playwright tests. Use cases zijn maar gewone, tekstuele beschrijvingen van wat de applicatie moet doen. Hoewel een coding agent vaak prima in staat is die tekstuele beschrijving om te zetten naar een werkende test, is dat doorgaans langzaam en duur. Je agent doet al het zware werk en dat kost je je tokens. Een beter alternatief is het om je use cases te converteren naar Playwright tests, die je volautomatisch kunt draaien. Snel en scheelt tokens. Het converteren van use cases naar Playwright tests is wél een duur proces, een typische taak voor als je al van plan was iets anders te doen.
Afsluitende E2E check. Als je een werkpakket hebt afgerond, dan draai je de volledige E2E suite om te kijken of al je tests werken. Je zult hiervoor een applicatie in de lucht moeten brengen met een "verse" database, waar je tests op geschreven zijn. Een uitdaging is flakiness (een test die some wel en soms niet werkt) en slecht geïsoleerde tests. Over de tijd kun je dat stabieler maken, daarom is het belangrijk dat je coding agent de resultaten analyseert en suggesties doet voor het robuuster maken van je E2E testsuite.
Synchroniseren use cases en tests. Omdat het makkelijk is om iets te vergeten, is het zaak om regelmatig te verifiëren of use cases en Playwright tests nog in overeenstemming met elkaar zijn. De check geeft je advies of je je use cases of juist je tests moet herschrijven. Dit zorgt dat de E2E testsuite courant blijft en de status van je applicatie goed representeert.
Wat heb je nu gewonnen?
Eén van de meest lastige problemen met web applicaties is dat regressie in schermen niet goed gedetecteerd wordt met de meeste tests. Een End-to-End test pakt alle schakels mee en komt dezelfde fouten tegen als die mensen tegenkomen. Dat maakt dat een goede E2E testsuite de kans significant verlaagt dat functies uitvallen na opleveren van een nieuwe release. De kwaliteit van het product is beter en de zekerheid waarmee een release wordt uitgerold is hoger. Omdat de test niet duur is om te draaien, kun je de suite onderdeel maken van het development proces, zodat je vroeg (left-shifted) fouten detecteert en oplost.
