Als je begint met component testen is het verstandig om klein te beginnen en nog niet te veel tijd te stoppen in code abstractie en helper classes. Maar naarmate je component testen meer gaat gebruiken, heeft het waarde om zo’n framework juist uit het schrijven en bepaalde logica te hergebruiken.
Het helpt een team enorm als je bij een user story een test kan meegeven die al werkt zonder dat hier nieuwe code voor geschreven hoeft te worden, zoals:
Maar ook als je geen cucumber gebruikt kun je testen in code ook op eenzelfde manier opzetten:
Maar hoe kom je nou tot zo’n behulpzaam framework?
Als je net begint met component testen, weet je nog niet welke code vaak gebruikt gaat worden (veel mensen denken wel dat ze het al weten, maar dat klopt niet). Vaak kom je hier pas achter als je het framework al een tijdje gebruikt. Want dan zie je vanzelf welke code vaak hergebruikt wordt.
Daar ligt ook de oplossing! Omarm die aanpak en probeer het niet van tevoren te bedenken.
Wat ik aanraad is dat iedere keer dat je nieuwe component testen hebt geschreven, je herevalueert hoe makkelijk dit ging. Heb je veel nieuwe custom code moeten schrijven om je testen te laten draaien (meer dan de toegevoegde productie code bijvoorbeeld)? Dan is het waarschijnlijk de moeite waard om je code wat beter op te zetten met meer helper classes die je vaker kunt hergebruiken in de toekomst. Ging dit soepel? Dan is dat juist een reden om je framework zo te houden.
Component testen zijn anders dan normale unit of integratie testen, omdat je veel testen schrijft die tegen dezelfde interfaces praten (zoals API endpoints). Daarom zal er meer herbruikbare code te schrijven zijn dan voor een unit of integratie test.
Kijk hierbij naar terugkerende patronen in je testen:
- moet je veel verschillende documenten genereren die je component moet verwerken? Gebruik default bronbestanden en gebruik helper classes om deze aan te passen naar wat je nodig hebt.
- Heb je veel uiteenlopende json objecten die je via POST of PUT requests wilt inschieten? Maak een generieke methode die bestanden uit je resource folder leest en inschiet via een endpoint.
- Heb je veel verschillende autorisatie eisen? Schrijf een eigen authenticatie mock zodat je allerlei verschillende json tokens kunt genereren die je kunt gebruiken via een API endpoint.
Dus kijk terug naar de vorige component test die je hebt geschreven. Ging dat makkelijk? Of zou het een goede investering zijn om toch een paar verbeteringen aan te brengen op jullie framework?
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
