Een nieuwe manier van old-school testing
De imperfecte software leidt ertoe dat ontwikkelaars achterblijven met de afweging: test de software voorzichtig en rigoureus om alle problemen vóór de implementatie te vinden, of test minder en verzend sneller met een grotere tolerantie voor bugs in productie. Het eerste kamp is gevuld met ontwikkelaars die werkzaam zijn in gereguleerde sectoren zoals gezondheidszorg en financiën; de laatste wordt bevolkt door aanhangers van “you build it, you run it” de beroemde uitspraak van Werner Vogels (zie de pdf in de link).
Deze afweging is een van de meest genuanceerde debatten over productiviteit van ontwikkelaars.
Er is geen pasklare oplossing voor het testen van software, waardoor ontwikkelaars voortdurend op zoek zijn naar de juiste mix van testbenaderingen om aan hun veranderende behoeften te voldoen. Om de zaken nog ingewikkelder te maken, moeten ontwikkelaars, voordat een van de beschikbare testbenaderingen een gewoonte wordt, de goede plek vinden om zowel een belangrijk pijnpunt op te lossen als niet zo onbetaalbaar traag of ingewikkeld te zijn dat ze het niet zullen gebruiken.
Unit testing heeft de sweet spot gevonden. Als een softwaretestpraktijk, stelt het teams in staat om kleine, geïsoleerde stukjes code te testen, wat niet alleen verzekert dat de software werkt volgens de beoogde specificaties, maar ontwikkelaars ook in staat stelt om te redeneren met delen van de codebasis die door andere ontwikkelaars zijn geschreven. Het testen van eenheden bestaat al tientallen jaren, maar het is pas recentelijk ingeburgerd geraakt omdat automatisering de gebruikerservaring heeft vereenvoudigd tot het punt van echte bruikbaarheid.
Tegenwoordig is er een andere vorm van testen die, vergelijkbaar met unit testing, tientallen jaren in de maak is, maar nu pas zijn goede plek vindt in zowel het aanpakken van een essentieel probleem als het geven van de juiste abstractie aan ontwikkelaars voor een sterk vereenvoudigde aanpak. Ik heb het over integratietesten.
In conventionele drielaagse architectuursystemen hadden ontwikkelaars misschien één database en misschien een of twee API’s om mee te werken, en dat was de omvang van de componenten van derden die ze aanraakten.
Tegenwoordig hebben ontwikkelaars de neiging om een oplossing op te splitsen in veel verschillende componenten – waarvan ze de meeste niet hebben geschreven, de meeste waarvan ze de broncode niet hebben gezien, en veel daarvan zijn geschreven in een andere programmeertaal.
Ontwikkelaars schrijven minder logica en besteden meer tijd aan het aan elkaar lijmen van dingen. Tegenwoordig heeft het gemiddelde productiesysteem interactie met meerdere databases, API’s en andere microservices en eindpunten.
Elke keer dat uw software met een ander stuk software moet praten, kunt u geen eenvoudige veronderstellingen meer maken over hoe uw systeem zich gaat gedragen. Elke database, berichtenwachtrij, cache en framework heeft zijn eigen specifieke statussen, regels en beperkingen die het gedrag ervan bepalen. Ontwikkelaars hebben een manier nodig om dit gedrag te testen voordat ze worden geïmplementeerd, en deze testklasse wordt integratietesten genoemd.
“Integratietests bepalen of onafhankelijk ontwikkelde software-eenheden correct werken wanneer ze met elkaar zijn verbonden”, schrijft Martin Fowler , die in de jaren tachtig voor het eerst kennismaakte met integratietesten.
Tot voor kort betekende integratietesten dat je een replica van je productieomgeving nodig had. Het met de hand maken van die testomgeving was een enorm tijdrovend proces, met een groot risico op fouten. Er waren sancties voor het hebben van discrepanties tussen test en productie, en er was de voortdurende last om elke keer dat u een wijziging in de productie aanbracht wijzigingen in uw testomgeving aan te brengen. Integratietesten was zo moeilijk op te zetten en te gebruiken dat het voor veel ontwikkelaars een obscure, ontoegankelijke discipline voor het testen van software bleef.
Dat was toen. Dit is nu.
Richard North creëerde Testcontainers in 2015, terwijl hij hoofdingenieur was bij Deloitte Digital. Hij merkte op dat de hopeloos gecompliceerde setup van integratietesten – van het creëren van consistente lokale setups tot het configureren van databases en het beheren van talloze andere problemen – een constante bron van narigheid was voor ontwikkelaarsteams die een betrouwbare manier nodig hadden om hun code te testen op echte productie-achtige afhankelijkheden.
North heeft Testcontainers gebouwd als een open source-bibliotheek waarmee ontwikkelaars kunnen “testen met containers” tegen datastores, databases of iets anders dat in een Docker-container kan worden uitgevoerd, inclusief populaire frameworks zoals Apache Kafka. Testcontainers biedt een ergonomische, op code gebaseerde manier voor ontwikkelaars om containers te gebruiken voor lokale en continue integratietests, zonder dat elke ontwikkelaar een expert hoeft te worden in de vele nuances van containers.
Vandaag de dag is Testcontainers de populairste op Docker gebaseerde bibliotheek voor het testen van integratie, die wordt gebruikt door duizenden bedrijven, zoals Spotify, Google, Instana, Oracle en Zalando. Een deel van de populariteit van Testcontainers is de vooraf ondersteunde bibliotheek met modules die zowat elke bekende database en veel populaire technologieën bevat, vaak bijgedragen aan het Testcontainers-project en rechtstreeks onderhouden door de database- en technologieleveranciers. Eerder dit jaar ontving Sergei Egorov, de beheerder van North en Core Testcontainers, $ 4 miljoen aan seed-financiering en lanceerde AtomicJar om het ecosysteem van ondersteunde Testcontainers-modules te blijven uitbreiden.
Er zullen altijd gepassioneerde discussies zijn over de beste balans tussen snelheid en softwarekwaliteit. Een van de redenen voor de grote populariteit van de Java-compiler en soortgelijke technologieën is hun vermogen om ontwikkelaars te helpen fouten dichter bij het punt van ontwikkeling te vinden, zodat ze deze snel kunnen oplossen.
Er zullen altijd duivelse bugs zijn die je testen ontwijken, maar met het toenemende gemak van het testen van software-eenheden en het testen van integratie tegenwoordig, wordt het steeds moeilijker om geloofwaardig te argumenteren tegen het investeren van meer cycli in het testen van je code en het integratie-oppervlak voordat je naar productie gaat.
Bron: Infoworld
