In bovenstaand voorbeeld zie je twee applicaties die draaien op een end-to-end omgeving. Een providerapplicatie genaamd Amazing en een consumerapplicatie genaamd Belle. Amazing en Belle kunnen via een API met elkaar praten. We voeden de applicaties met alles wat ze nodig hebben om te draaien. Denk aan omgeving specifieke afhankelijkheden zoals data, certificaten, etc. Met deze setup kunnen we beginnen met testen.

Wanneer we een test uitvoeren, doen we dit vanuit een aparte omgeving zoals een laptop of een pijplijn. De complexiteit ligt volledig in de end-to-end omgeving.

Goede eigenschappen van end-to-end testen

Testen op deze manier is zeer effectief. Door de op productie lijkende omgeving, kunnen we alles testen wat er op productie kan voorkomen. Het is dan ook geen wonder dat deze manier van testen populair is. In een oogopslag is het voor iedereen duidelijk waarom end-to-end testen nuttig zijn. Onderstaand de voordelen op een rijtje:

• Complexe interacties testen
• Functionele testen
• Technische testen
• Handmatige testen
• Business kan functies previewen
• Productieproblemen naspelen
• Hoogst mogelijke dekking per test

Bron van hoofdpijn

Ondanks de geweldige mogelijkheden van end-to-end testen, bezorgt het mij toch vooral hoofdpijn. En wel om de volgende redenen:

• Valse negatieven in je testen
  Dit is vooral het geval wanneer teams snel naar productie gaan. Veel applicaties in end-to-end omgevingen draaien elke dag meerdere versies, zonder dat vooraf te melden. Al deze versies – waarvan sommige niet getest zijn – schaden de stabiliteit van de omgeving. Een ander effect hiervan is dat de testresultaten je niet kunnen vertellen of het werkt met de productieversies.
• Het duurt lang om testen uit te voeren
  Bij het opstellen en uitvoeren van testen ben je vaak afhankelijk van andere teams. Bijvoorbeeld voor het toevoegen van data aan hun database. Dit vertraagt de testuitvoering omdat elk team haar eigen planning en prioriteit heeft. Deze vertraging is nog pijnlijker wanneer je data nodig hebt die in meerdere applicaties moet worden gesynchroniseerd voordat jouw testen slagen.
• Onderhoud kost veel tijd
  End-to-end omgevingen hebben de neiging om veel testen te hebben en – op een gegeven moment – hebben deze allemaal onderhoud nodig. Dit is geen probleem als we volledige controle hebben over alle delen van de testen, maar sommige delen van onze testen zijn onderdeel van andere applicaties en vice versa. Dit zorgt voor situaties waarin niemand weet wat deel uitmaakt van welke test en of het weggegooid kan worden. Hierdoor wordt de omgeving langzaam vervuild met onderdelen van buiten de bedrijf gestelde testen.

Het probleem van tight coupling

Interessant aan de hierboven genoemde punten, is dat ze allemaal veroorzaakt worden door hetzelfde probleem, namelijk: tight coupling. We verstrengelen onze applicaties en teams zodanig met elkaar dat het onmogelijk wordt om zaken als data en versies effectief te beheren. De betrokken teams zijn constant afhankelijk van elkaar. Voor mij is het resultaat aan het eind van de dag hoofdpijn.

Langzame feedback

De laatste bron van hoofdpijn is de langzame feedback die end-to-end testen opleveren. Met een continuous integration pipeline krijgen we binnen enkele minuten testresultaten van low-level testen. End-to-end testen zijn doorgaans langzame processen. Wanneer we deze high-level testen aan de pijplijn toevoegen, wordt onze feedbacktijd dramatisch verlengd, vaak met een factor van 10. En dat veronderstelt dat:

• Alle testen worden uitgevoerd.
  Niet alle testen uitvoeren is een slecht idee, omdat je mogelijk een probleem mist. Doe niet af aan de kwaliteit van je test run door testen over te slaan.
• Alle end-to-end testen zijn geautomatiseerd.
  Handmatige testen opnemen in een continuous integration pipeline is een slecht idee. Het zal de feedbacktijd verlengen tot wanneer-de-tester-de-tijd-heeft-om-ernaar-te-kijken, wat ontwikkelaars heel irritant zullen vinden.
• De end-to-end omgeving is stabiel gebleven tijdens het testen.
  Voorbeeld: Een applicatie waarvan je afhankelijk bent, krijgt een nieuwe release terwijl je jouw testen uitvoert. Deze release veroorzaakt enige downtime waardoor jouw testen falen. Je analyseert de fout en herstart de pijplijn. Alweer. Hierdoor neemt je feedback time nog meer toe.

Deze langzame feedback leidt tot een langere time-to-market voor alle wijzigingen in jouw applicatie, inclusief bug fixes. Dit heeft een directe impact op de ervaring van de eindgebruiker en de intensiteit van mijn hoofdpijn.

Geen hoofdpijn meer

Contract-based testen kan veel van onze hoofdpijn verlichten, maar het is niet dé perfecte oplossing voor elke situatie. Er zijn er die denken dat alle end-to-end testen kunnen worden vervangen door contract-based testen. Dat kan voor sommige applicaties het geval zijn, maar het moet nooit een doel op zich zijn.

End-to-end testen is geen slechte manier van testen, maar het is wel een zeer tijdrovende die spaarzaam gebruikt moet worden. Vergeet niet dat contract-based testen onder end-to-end testen wordt geplaatst in de test piramide. Het is dus geen vervanging van. Ik schat dat we in mijn geval ergens tussen de 70% en 95% van alle end-to-end testen kunnen vervangen door contracttesten.

Hoe contract-based testen precies je hoofdpijn kan verlichten, leg ik uit in het volgende deel van mijn blogreeks.

Met dank aan Vilas Pultoo voor de illustraties

Ben jij geïnteresseerd in contract-based testen?

Luister dan ook onze podcast waarin Sander van Beek en Stephan Dammers in gesprek gaan over dit onderwerp. Sander maakt jou wegwijs in de wereld van contract-based testen en vertelt uitgebreid over zijn ervaringen, wanneer contract-based testen wordt ingezet, de te verwachtte trends en nog veel meer. Je luistert de podcast via ons SoundCloud account.