Discussies kunnen eindeloos duren, zonder dat er acties uit voortkomen. Met name tijdens discussies over technische thema’s kunnen de opvattingen nogal verschillen. Ook de verschillende kennisniveaus van deelnemers kunnen hierbij een rol spelen. Niet alleen kan een discussie dan onnodig lang duren, ook afspraken of vervolgacties kunnen volledig de plank misslaan.
Testautomatisering in de software is zeker een van de onderwerpen waar dit regelmatig voor komt. Als je het over testautomatisering hebt, is het gesprek altijd gebaseerd op ieders eigen (heel verschillende) kennis en ervaring. Als er geen gezamenlijke opvatting is van testautomatisering, inclusief toepasselijke best practices, kan de geïnvesteerde tijd maar beperkt effectief zijn.
Ook bij AgroVision waren er uiteenlopende opvattingen ontstaan over unit testen. Daarom heeft KZA een workshop verzorgd over ‘unit testing’. Precies zo’n term waar snel begripsverwarring over kan ontstaan. Het doel van deze workshop was met name om een gezamenlijk begrip van unit testing te creëren en zo discussies binnen AgroVision een goed fundament te geven. Door complete Agile teams bij de introductiesessie te betrekken, ontstaat een eenduidig beeld en kan iedereen meedenken over de meerwaarde en implementatie van deze tests. Unit tests schrijven is automatiseren, daarover is eigenlijk iedereen het vaak wel eens. Toch komen wij verschillende interpretaties tegen.
Daarom begonnen we de workshop met deze vraag: Wat is testautomatisering precies en waarom zouden we er überhaupt tijd aan besteden?
Aan de hand van de testpiramide hebben we gekeken naar de verschillende lagen van automatisering in een applicatie aan de hand van het voorbeeld van forenzen met het openbaar vervoer. Stel je de volgende situatie voor, toen je nog naar kantoor mocht, zag de reis er zo uit: vanaf thuis neem je de fiets naar het station. Daar parkeer je jouw fiets en stap je in de trein. Vervolgens stap je op het station dicht bij jouw werk uit en wandel je naar jouw werk.
Deze hele reis kan je zien als een end-to-end (E2E) test, tenslotte heb je elke stap nodig om op je eindbestemming te komen. Een integratie test zou zijn dat je alleen jouw fiets zou parkeren op het station en dat je vervolgens in de trein zou stappen. Je test dan alleen de integratie van jouw fietstocht met de treinreis. Als laatste kunnen we ook alleen de binnenband van de fiets testen, zonder dat je daadwerkelijk gaat fietsen of de hele reis gaat maken. Het in isolatie testen van de binnenband kan je zien als een unit test. Hierna bespraken we de voor- en nadelen van automatisering in iedere laag in de testpiramide. Door dit soort onderwerpen gezamenlijk te behandelen weten we zeker dat iedereen dezelfde opvatting heeft van unit testing.
Hierna zijn we met de ontwikkelaars op een aantal (technische) details ingegaan. In tegenstelling tot wat de kop van dit artikel adviseert, hebben we met de ontwikkelaars juist veel gediscussieerd. De context in deze situaties is cruciaal. Hoe kunnen unit tests een toevoeging zijn op onze huidige werkwijze? Hoe kunnen we dit gefaseerd implementeren? Wat zijn robuuste unit tests? Ook hebben we correcte implementatie in de CI-pipeline behandeld. Dit was ontzettend waardevol en is het fundament geworden voor vervolgontwikkeling.
De titel van deze blog, ‘begin vooral niet met discussiëren’, wil niet zeggen dat je discussie weg moet laten. Integendeel, dit is het belangrijkste wat er is. Maar wel vanuit een gezamenlijke opvatting. Dus: eerst context afstemmen, dan discussiëren. Dat helpt je écht met automatiseren.
Edward Becx