Ik kan me nog goed herinneren dat ik werkte aan testing frameworks die nachtelijks gedraaid werden. De volgende ochtend keek je naar het resultaat van de testen en begon je te analyseren wat er aan de hand was. Dit nam vaak flink wat uurtjes in beslag. De ene keer viel een test om vanwege een schrikkeljaar, de andere keer was er een printscreen- vergelijking gefaald omdat er ergens op de pagina een label was toegevoegd. Of een service waar we afhankelijk van waren, werkte even niet goed. Vaak was er iemand fulltime nodig die deze taak op zich nam.
Vier jaar geleden begon ik te werken met component testen. Ik was hier al wat langer in geïnteresseerd vanwege wat slides van Martin Fowler over het testen van microservices, maar kwam nooit in de gelegenheid om hier iets mee te doen bij de klant. Maar deze vorm van testen heeft de manier hoe ik tegen software testen aan keek drastisch veranderd. In plaats van focussen op een volledig systeem, gaat het bij component testen om “het testen van een enkel component in isolatie”.
Bij component testen schrijf je testen voor één enkele microservice. Je vervangt alle afhankelijkheden die deze microservice heeft, zodat deze in een geïsoleerde context opgestart kan worden. Zo vervang je complexe databases met lightweight databases, zoals H2 of Postgres, en vervang je externe afhankelijkheden met stubs.
Omdat je context nu relatief klein is en volledig onder controle, is het schrijven van testen een stuk makkelijker geworden. Testdata problemen zijn hier ook een stuk kleiner, en falende testen wijzen veel sneller een probleem aan. Als er iets fout gaat weet je ook zeker dat het in je microservice zit, want je afhankelijkheden zijn vervangen met stub bestanden.
Met component testen verplaats je de focus van het hele systeem, naar een enkel component. In mijn visie betekent dit dat als ieder component goed getest is en goed werkt, de overgebleven risico’s van het systeem als geheel beperkt blijven. Afhankelijk van het product risico kun je hier nog extra testvormen aan toevoegen, maar component testen zorgen voor de kwaliteit van de microservices zelf, en zijn daarmee de basis van een solide teststrategie in een microservice landschap.
Tot slot
Sinds vier jaar zet ik nu component testen in bij klanten. En de ervaringen zijn ver boven verwachting. Developers geven aan dat ze hierdoor sneller software kunnen leveren en hier goed op kunnen vertrouwen tijdens refactoring. Ook de samenwerking tussen testers en developers verloopt een stuk soepeler, omdat beide disciplines hier waardevol kunnen zijn. Developers leren nadenken vanuit risico’s, en testers leren meer over de techniek van de applicatie.
Als jij zelf wilt leren hoe je component testen kunt opzetten bij je klant, volg de online cursus: https://academy.praegus.nl/cursus/component-testen-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
