Auteur: Bas Dijkstra ● bas@ontestautomation.com
Redactie: Henk Johan Kwakkel
Volgens mij vertel ik niet heel veel nieuws als ik zeg dat unit tests de basis vormen voor de solide testautomatisering. Unit tests zijn kleinschalig, doelgericht, kosten relatief weinig tijd om te schrijven (tenminste, als je code fatsoenlijk testbaar is geschreven) en heel weinig tijd om uit te voeren. De voordelen zijn legio.
Feestje voor ontwikkelaars?
Het is niet voor niets dat unit tests de basis vormen van de welbekende testautomatiseringspyramide (waar ik het verder hier niet over ga hebben, die is vaak genoeg besproken). Wat ik in de praktijk nog wel regelmatig zie en ook wel vaker hoor van collega-testers en ontwikkelaars, wanneer het ter sprake komt: is dat unit testing toch vaak nog wel gezien wordt als een taak voor / feestje van de ontwikkelaars (doorhalen wat niet van toepassing is).
Voor veel testers is het kunnen bijdragen aan unit tests nog een ver-van-mijn-bed-show. Als ik vraag naar de reden waarom, is iets als “je moet de code begrijpen om unit tests te kunnen lezen en schrijven” wat vaak naar voren komt. En dat klopt natuurlijk, unit tests zijn nu eenmaal tests tegen code die worden geschreven in code. Dat maakt, denk ik, dat veel testers unit tests nog als ‘moeilijk’ zien en daarom bewust of onbewust er met een boog omheen lopen.
Het vreemde is, we spenderen als testers tegenwoordig vaak wel veel tijd aan testautomatisering op API- of UI-niveau. En die tests zijn (vind ik zelf) veel moeilijker te schrijven dan unit tests. Ga maar eens kijken naar de hoeveelheid code die nodig is om een gemiddelde test met Selenium (of Cypress, of Puppeteer, of …) fatsoenlijk op te zetten en ga dat eens vergelijken met een unit test. Je zult zien dat die laatste veel minder code vereist. Vervolgens als je iets beter kijkt, is die test ook vaak helemaal niet zo complex als het op het eerste gezicht lijkt.
Geen excuus (meer) als tester
Ik denk dat we als testers niet meer weg (zouden moeten willen) komen met het excuus dat unit tests ‘moeilijk’ zijn. Ja, ze vereisen wat andere vaardigheden dan andere typen tests. Ja, het is nodig dat je, je comfortabel voelt bij het lezen en begrijpen van code. Zelf code kunnen schrijven is handig, maar niet eens noodzakelijk om een bijdrage aan unit tests te kunnen leveren, maar daar kom ik later nog op terug.
Met andere woorden, ik vind dat testers zich best wel wat vaker met unit tests zouden mogen bezig houden. Maar hoe begin je daar dan mee? Zoals met zoveel andere zaken in het leven: stap voor stap.
Stel vragen
Begin bijvoorbeeld eens met naar een developer toe te lopen en te vragen of hij of zij je eens door een deel van de unit tests heen wil praten. Wat wordt er nu eigenlijk getest? Hoe zit de unit test in elkaar? Waar wordt er gebruik gemaakt van mocks? Dat geeft je als tester ook meteen inzicht in de gedachtegang van de developer en misschien zie je wel meteen waar er nog een testgeval of grenswaarde ontbreekt…
Doe-het-zelf en experimenteer
Een volgende stap zou kunnen zijn om de applicatiecode inclusief unit tests eens op je lokale machine te zetten. Met een versiebeheersysteem als Git is dat zo gedaan. Vervolgens kun je lokaal de unit tests uitvoeren, eventueel met hulp van een developer. Pik er eens een test uit, liefst één die voor jou een bekend stukje functionaliteit of logica is. Het is makkelijker om te kijken hoe zo’n test werkt als je bekend bent met wat er moet worden getest en wat de verwachte uitkomst is. Kijk eens of je de test kunt laten falen, bijvoorbeeld door het verwachte resultaat aan te passen en wat de informatie is die je krijgt. Kun je daaruit afleiden wat er verkeerd is gegaan? Zo niet, bespreek dat dan eens met een developer.
Als je, je op deze manier langzaam wat meer thuis voelt en bekend wordt met de bestaande unit tests, zou je voor een nieuwe feature of misschien nog beter, voor een bug of incident eens samen met een developer aan de slag te gaan. Vervolgens om daar, naast de applicatiecode een goede set van unit tests voor te schrijven. Denk samen na over wat de code moet doen en hoe je dat zou kunnen testen. Wie uiteindelijk de unit tests schrijft maakt mij persoonlijk niet zo heel veel uit. Het gaat erom dat je dit met zijn tweeën of misschien wel met nog meer doet. Twee weten meer dan één en met jouw ervaring als tester kun je goede tests bedenken waar een developer misschien niet zo snel aan denkt en je deelt meteen wat kennis over een deel van de functionaliteit van de code.
Geen doel op zich
Het is uiteindelijk natuurlijk niet het doel om als tester alleen verantwoordelijk te worden voor de unit tests. Daarmee creëer je alleen maar schuttingen en muurtjes die ik nu juist zo graag zou zien verdwijnen. Ik denk wel dat je als tester een grote bijdrage kunt leveren aan de kwaliteit van je applicatie door je eens wat meer te verdiepen in de unit tests. Alles wat je daarmee test hoef je niet later nog eens zelf af te dekken en het scheelt wellicht ook weer één of meer duurdere en langzamere integratie- of end-to-end tests.
Ten slotte
Als je nog eens wat meer wil horen en leren over unit tests, kan ik je deze gratis online training van Tariq King op Test Automation University aanbevelen: https://testautomationu.applitools.com/unit-testing/.
Unit testen worden naar mijn idee vooral door ontwikkelaars gedaan omdat zij toch al bezig zijn met die code.
Om te beginnen met de bron code kan een tester ook waarde bieden door mee te doen met code reviews (bijvoorbeeld via Pull Requests). Misschien ziet de tester in het begin alleen spelfouten, maar met wat focus op de testen geschreven door de ontwikkelaar kun je zeker bijdragen. Als tester kun je ook in de code zien of de unit testen doen wat je zou verwachten aan de hand van de titel van de test, de input waardes, etc. En je leert een heleboel over hoe het project in elkaar steekt.
Als tester die vanuit het vak van ontwikkelaar in mijn huidige werkgebied terecht is gekomen, geloof ik niet dat de tester iets te maken moet hebben met de unit tests binnen het project. De tester controleert “of” de applicatie werkt. “Hoe” de applicatie werkt is aan de ontwikkelaar, en is in principe niet van belang voor de tester.
Aangezien de ontwikkelaar de persoon is die het plan trekt voor “hoe” het doel van de applicatie wordt bereikt, is hij degene die de meeste kennis heeft van de input en output die elke onderliggende functie dient te leveren. Bij het opzetten van de unit test is daarom geen communicatie nodig wanneer hij die zelf opzet, het gebeurt op nagenoeg hetzelfde moment wanneer de code geschreven wordt. Wat mij betreft is dan de meest efficiënte aanpak dat de ontwikkelaar zelf de unit tests afhandelt.
Wel vind ik het van waarde dat de tester het concept van een unit test goed begrijpt, zodat deze een duidelijk beeld heeft van welke type issues wordt opgevangen door deze vorm van testen: wat dat betreft is het voor een tester zeer positief om een keer een middagje met een ontwikkelaar door te brengen zodat hij kan zien hoe dat in z’n werk gaat.