Component testen helpen steeds meer teams om grip te krijgen op de kwaliteit van hun microservices. Refactoren wordt een stuk minder pijnlijk en hierdoor wordt het ook makkelijker om de code van je microservice continu te blijven verbeteren. Maar hoe begin je nu met het schrijven van component testen?
Zoek een stuk functionaliteit van je microservice dat technisch simpel is en functioneel relevant.
Technisch simpel houdt in dat je zo min mogelijk technische complexiteit krijgt in je component test. Als je begint met een test die afhankelijk is van allerlei complexe technologieën (event driven, rest based, tijdreizen, configuratie parameters, feature toggles etc.) dan gaat het schrijven van je component test ook erg lastig worden en veel tijd kosten. Uiteindelijk zal je alle technische complexiteit van je microservice wel moeten tackelen, maar het is verstandig dit niet direct te doen.
Door een stuk te kiezen dat functioneel relevant is, krijg je direct een scenario dat veel waarde zal hebben als testdekking voor je microservice. Je kunt ook beginnen met het testen van een /health endpoint, maar het risico is dat je component testset hiermee niet serieus genomen gaat worden en vrij snel uitgezet gaat worden zodra het onderhoud te moeilijk wordt. Een falende test die kritische functionaliteit dekt, is een stuk moeilijker te negeren.
Breek het werk op in kleine stapjes
Het toevoegen van een component test kan vaak voelen als een hoge berg met veel onzekerheden. In zo’n situatie is het vaak moeilijk om te beginnen aan zo’n opgave. Om je op weg te helpen zijn dit kleine subtaken die ik (vaak in mijn hoofd) stuk voor stuk tackle:
- Voeg de test class toe die verantwoordelijk is voor het opstarten van je microservice en laat deze test een simpel endpoint opvragen (health endpoint?), en check dat deze een 200 code teruggeeft (voor java gebruik ik hier meestal RestAssured voor)
- Zoek uit hoe je binnen jouw framework de microservice kan laten opstarten als onderdeel van je test (quarkus = @QuarkusTest, spring = @SpringBootTest). Voeg deze configuratie toe aan je test class
- Draai je test en los 1 voor 1 de errors op die je tegenkomt totdat je microservice opstart en je test inderdaad je health endpoint kan raadplegen
- Voeg een tweede test toe waarin je de actie uitvoert van de functionaliteit die je wilt testen (bijvoorbeeld door een rest endpoint op te vragen waarmee een complexe berekening gedaan wordt). Bewaar je eerste test zodat je hier altijd op kunt terugvallen als je iets aanpast in je applicatie configuratie
- Voeg een simpele assert toe onderaan je test die je kunt gebruiken om een breakpoint te zetten om het resultaat van je actie handmatig te controleren
- Draai je test en kijk wat in eerste instantie het resultaat is
- Voeg nu testdata toe aan het begin van je test, totdat het antwoord van je actie zoals verwacht is
- Pas nu je assertions aan zodat je test faalt zodra de functionaliteit omvalt, maar maak tegelijkertijd je test niet te brittle (doe geen assertions op waardes die niet echt relevant zijn; probeer je validaties klein en specifiek te houden)
- Refactor je code zodat je test leesbaar is, en de code die je wellicht wilt hergebruiken in losse helper classes geplaatst wordt
- Check of je test al direct in je geautomatiseerde pipelines meedraait en zo nee, zorg daarvoor
- Zorg voor een nette rapportage als je test faalt (als de build faalt op deze test, wil je het liefst dat je developers gemakkelijk dit rapport kunnen openen en zien wat er stuk is)
- Maak de Pull Request die je teamleden kunnen reviewen om je component test voortaan mee te laten draaien in iedere build.
Heb je nog hulp nodig?
We hebben een gratis online cursus gemaakt waarmee je leert hoe je verschillende technische uitdaging kunt tackelen, zodat je de kennis kunt opdoen om je eerste component test zelf te schrijven.
Nieuwsgierig geworden en wil je meer weten over testen? Neem dan contact op met Praegus – 085-1305977 / info@praegus.nl of kijk op www.praegus.nl
