E2E-testen: A Tutorial and Architectural Guide

End-to-end (E2E) tests helpen bij het valideren van de belangrijkste stromen in uw applicatie, zoals inlogverzoeken van gebruikers. Voor front-end ontwikkeling helpen E2E-tests te verifiëren of de juiste UI is gepresenteerd. Voor back-end ontwikkeling helpen E2E-tests om te verifiëren of een belangrijke flow in uw back-end services de verwachte output retourneert.

Dit bericht laat u kennismaken met E2E-tests en geeft u bruikbare tips. We zullen ook uitleggen hoe u herbruikbare tests kunt schrijven, zodat deze gemakkelijker kunnen worden gebruikt om E2E-tests te maken. Zoals u wellicht weet, zijn E2E-tests vaak een grote frustratie voor ontwikkelaars, omdat ze veel inspanning vergen om te schrijven, uit te voeren en te onderhouden.

Laten we eerst eens kijken naar waar E2E-tests zich bevinden in de piramide van het testen van software.

De plaats van E2E-tests in de testpiramide

Wanneer we naar de testpiramide kijken, vinden we vier belangrijke testtypen om ons te helpen de kwaliteit van de code te garanderen:

  1. E2E-tests helpen bij het verifiëren van hoogwaardige paden in uw applicatie. Met andere woorden, ze helpen verifiëren user stories als ze vaak vertegenwoordigen stromen in uw applicatie.
  2. Integratie testen helpen verifiëren van de integratie van meerdere functies of componenten. Integratie testen kunnen u vertellen of uw code werkt cohesief met andere functies.
  3. Unit tests helpen verifiëren van de business logica van functies. Unit tests zijn de meest elementaire vorm van testen, en ze zorgen ervoor dat de business logica correct is.
  4. Tot slot kunnen we niet vergeten over statische analyse of statisch testen. Statisch testen helpt bij het vinden van typefouten of typefouten.

Volgens deze piramide zouden de meeste tests unit-tests moeten zijn, met minder integratietests en nog minder E2E-tests. Het is echter nog steeds belangrijk om de stromen in uw applicatie te verifiëren. E2E testen zijn moeilijk te onderhouden en vergen veel inspanning. Verifieer daarom alleen de belangrijkste flows met E2E-tests. Andere soorten testen, zoals integratie- en unit-testen, zouden u al voldoende vertrouwen in uw codebase moeten geven.

Verschillende E2E-teststrategieën

Laat me u vertellen dat er verschillende strategieën bestaan. We kunnen kiezen tussen horizontaal E2E testen en verticaal E2E testen. Beide strategieën zijn de moeite van het onderzoeken waard, omdat ze u in staat stellen verschillende scenario’s te testen. Laten we eens leren wat elke strategie doet.

Strategie #1: Verticaal End-to-End testen

Deze strategie richt zich op het testen van alle lagen van de testpiramide. Het omvat unit testen, integratie testen, en UI testen. Het doel is om een component op een granulair niveau te testen met unit tests, te testen hoe een component zich gedraagt bij interactie met andere componenten met integratietests, en ten slotte het gedrag van de component te verifiëren bij interactie van gebruikers via de UI.

Het meest gebruikelijk is om een continue integratie pijplijn te gebruiken om deze tests te automatiseren voor elke code commit of pull request.

Strategie #2: Horizontaal End-to-End testen

Horizontale E2E testen richten zich op het verifiëren van een complete gebruikersstroom. Hier is een voorbeeld van een flow voor een webshop:

  1. Open productpagina
  2. Selecteer productmaat
  3. Voeg product toe aan winkelmandje
  4. Ga naar checkout
  5. Vul adres- en betaalgegevens in
  6. Volg betaling
  7. Toon winkelbevestigingsscherm

Hier willen we elke transactie van de user flow verifiëren. Vaak wordt bij dit type testen de interactie tussen verschillende applicaties geverifieerd en worden toestandsveranderingen voor die applicaties geverifieerd.

Merk op dat dit soort testen duur zijn om te schrijven. Het kost nogal wat tijd om gebruikersstromen te definiëren en deze tests te schrijven. Probeer u daarom te richten op kritieke transactiepaden voor uw applicatie.

Zorg er echter voor dat u deze kritieke gebruikersstromen voor verschillende condities test. Deze strategie stelt u in staat om een compleet beeld te krijgen van de robuustheid van de user flow. Deze omstandigheden omvatten:

  • Complexe timingscenario’s: Een concertticket is bijvoorbeeld slechts 15 minuten beschikbaar.
  • Verschillende gegevensinvoer of ontbrekende gegevens.
  • Flowonderbrekingen: Een gebruiker besluit de afrekenpagina te verlaten om een andere productpagina te bekijken. We moeten bijvoorbeeld controleren of de component de checkout-status opslaat.

Volgende, laten we leren wanneer je E2E-tests moet schrijven.

Wanneer E2E-tests schrijven

Je weet misschien niet dat E2E-tests dure tests zijn om uit te voeren in je continue integratiepijplijn. Ze vereisen vaak veel voorbereiding, zoals het maken van een database die productiegegevens nabootst. Bovendien vertegenwoordigen ze soms tijdrovende stromen in uw applicatie. Daarom kunnen ze traag zijn en meer resources vereisen om te worden uitgevoerd.

Gebruik E2E-tests om de belangrijkste flows in uw applicatie te verifiëren. Voorbeelden van hoogwaardige flows zijn:

  • Login en logout
  • Registreer een nieuwe gebruiker
  • Voeg een item toe aan winkelwagen
  • Wijzig uw wachtwoord
  • Alle andere belangrijke flows met betrekking tot uw service

Vergeet echter niet om de business logica die u schrijft te verifiëren met unit en integratie tests. De combinatie van zowel unit- als integratietests moet u veel vertrouwen geven over de kwaliteit van uw code. E2E-tests helpen u om dit vertrouwen voor kritieke paden te vergroten.

Hier volgen enkele bruikbare tips voor het schrijven van E2E-tests.

Tips voor het schrijven van E2E-tests

Focus on Writing Reusable Tests

De eerste en belangrijkste tip is om kleine, onafhankelijke, herbruikbare tests en componenten te schrijven. Dit stelt je in staat om meerdere kleine componenten aan elkaar te rijgen en zo gemakkelijker complete end-to-end user flows te maken. In plaats van veel aangepaste componenten te schrijven die alleen door E2E-tests worden gebruikt, moet u zich richten op het schrijven van herbruikbare componenten.

Het schrijven van kleine, onafhankelijke componenten helpt bij het hergebruik van code en vermindert de tijd die nodig is om fouten op te lossen. Ook is het eenvoudiger om kleine componenten te updaten wanneer de functionaliteit of gebruikersstromen veranderen.

Bedenk altijd de reden voor het schrijven van een E2E-test

Wanneer u een bepaalde flow wilt afdekken met een E2E-test, bedenk dan of het de moeite waard is om deze af te dekken. Test alleen gebruikersstromen met hoge waarde met E2E-tests. U moet bijvoorbeeld niet testen of een foutmelding wordt getoond wanneer een gebruiker een onjuist e-mailadres invoert. Dit is een veel te eenvoudige use case die niet past in een E2E test. Deze eis kan gewoon worden getest met een unit test.

Aan de andere kant is het de moeite waard om te testen of de inlogpagina u doorverwijst naar de juiste applicatiepagina nadat u met succes bent ingelogd. Dit is een waardevolle flow voor uw gebruikers om de applicatie te kunnen gebruiken. Kortom, bedenk altijd de reden voor het schrijven van een E2E test.

E2E Tests Shouldn’t Depend on Implementation Details

Je wilt E2E tests niet iedere keer updaten als je implementatiedetails voor een bepaalde flow wijzigt. Daarom wil je componenten schrijven die je in staat stellen implementatiedetails te abstraheren. E2E testen worden veel makkelijker te onderhouden, en leuker om te schrijven, wanneer implementatie details worden verborgen in componenten. Kortom, E2E-tests moeten onafhankelijk zijn van implementatiedetails.

Volgende, laten we eens kijken naar de valkuilen van E2E-tests.

Valkuilen van E2E-tests

Hier volgt een lijst van veel voorkomende valkuilen in verband met E2E-tests:

  • E2E-tests moeten niet proberen om zo veel mogelijk in één keer te testen. Vaak schrijven ontwikkelaars enorme E2E-tests die elk aspect van de gebruikersstroom verifiëren. Houd het simpel en controleer de belangrijkste aspecten van je user flow. Bijvoorbeeld, voor een login flow, hoef je alleen te controleren of de gebruiker wordt doorgestuurd naar de applicatie pagina. Dit maakt het voor ontwikkelaars eenvoudiger om E2E-tests te onderhouden en bij te werken.
  • Wanneer een E2E-test faalt, kan het moeilijk zijn om de exacte oorzaak van het falen te vinden. U kunt echter de vereiste debugging-inspanningen verminderen door uw bedrijfslogica af te dekken met unit- en integratietests. Sommige tools bieden ook een goede root cause analyse, inclusief screenshots en console logs van mislukte teststappen, wat de tijd voor troubleshooting kan verminderen.
  • E2E-tests vergen een aanzienlijke hoeveelheid tijd in uw continue integratie (CI) pijplijn. Ze kunnen uw CI-pijplijn blokkeren, wat de algehele ontwikkeling vertraagt. Dit betekent dat je misschien moet investeren in je CI-pijplijn om een paar extra pijplijnen te hebben voor het uitvoeren van tests.
  • E2E-tests zijn een continue inspanning. Elke keer als er nieuwe functionaliteit wordt toegevoegd of oude functionaliteit verandert, is het waarschijnlijk dat u uw E2E-tests moet bijwerken. We kunnen deze inspanning echter verminderen door herbruikbare componenten te schrijven die implementatiedetails abstraheren. Bovendien maken sommige tools gebruik van AI om de tests aan te passen wanneer de code verandert, waardoor het testonderhoud wordt verminderd.

Nog een korte blik op de verschillen tussen systeemtesten en E2E-testen.

Systeemtesten vs. E2E-testen – Wat is het verschil?

Dus, wat is het verschil tussen systeemtesten en E2E-testen? Systeemtesten zijn gericht op het valideren van zowel de functionele als de niet-functionele eisen. Vaak wordt het uitgevoerd door een extern team dat de applicatie als een black box behandelt. Met andere woorden, zij weten niets over het functioneren van de applicatie behalve aan welke eisen deze moet voldoen.

Deze vorm van testen wordt echter vaak verward met E2E testen, omdat systeemtesten een vorm van E2E testen is. Systeemtesten verifiëren echter veel meer dan E2E-testen. Bijvoorbeeld, systeem testen meet schaalbaarheid, prestaties, of betrouwbaarheid. Terwijl E2E-testen zich richt op de correcte afronding van gebruikersstromen.

Laten we tot slot de leerpunten van dit artikel samenvatten.

Conclusie over E2E

End-to-end tests zijn behoorlijk krachtig omdat ze helpen bij het valideren van hoogwaardige gebruikersstromen of user stories. Ze helpen de kwaliteit van uw applicatie te garanderen.

Het schrijven en onderhouden van E2E-tests kan echter veel tijd en moeite kosten. Het is mogelijk om deze inspanning te verminderen door kleine, herbruikbare componenten te schrijven die implementatiedetails abstraheren. Sommige tools helpen ook om meer veerkrachtige tests te maken door AI of meerdere attributen te gebruiken om elk element te identificeren. Zo hoeft u E2E-tests niet telkens te updaten wanneer implementatiedetails veranderen voor hoogwaardige gebruikersstromen. Bovendien kunt u herbruikbare componenten aan elkaar rijgen om eenvoudig E2E-testflows te maken.

E2E-tests moeten de belangrijkste flows van uw applicatie bestrijken. Zij testen de stromen die uw gebruikers en klanten volgen om waarde uit uw applicatie te halen. Als ze niet kunnen inloggen of een item toevoegen aan een winkelwagen, zullen ze ofwel vertrekken (als ze kunnen) of ondersteuning bellen als ze gedwongen worden om uw applicatie te gebruiken. U wilt bijvoorbeeld de login en logout flow afdekken, maar bent minder geïnteresseerd in het verifiëren van een foutmelding na het invoeren van een slecht email adres.

In the end, E2E tests moeten leuk zijn om te schrijven. Ze moeten niet veel tijd en moeite kosten om te schrijven en te onderhouden. Houd E2E-tests eenvoudig en focus op herbruikbare componenten, en je zult geweldige resultaten zien!

Dit bericht is geschreven door Michiel Mulders. Michiel is een gepassioneerde blockchain developer die houdt van het schrijven van technische content. Daarnaast houdt hij van leren over marketing, UX psychologie, en ondernemerschap. Als hij niet aan het schrijven is, is hij waarschijnlijk aan het genieten van een Belgisch biertje!

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.