E2E Testing: En handledning och arkitekturguide
End-to-end-testning (E2E) hjälper till att validera de viktigaste flödena i din applikation, t.ex. användarinloggningsförfrågningar. För front-end-utveckling hjälper E2E-testerna till att verifiera om rätt användargränssnitt har presenterats. För backend-utveckling hjälper E2E-tester till att verifiera om ett viktigt flöde i dina backend-tjänster returnerar det förväntade resultatet.
Det här inlägget kommer att introducera dig till E2E-testning och ge dig användbara tips. Vi kommer också att förklara hur man skriver återanvändbara tester så att de lättare kan användas för att skapa E2E-tester. Som du kanske vet är E2E-tester ofta en stor frustration för utvecklare eftersom de kräver mycket arbete att skriva, köra och underhålla.
Först ska vi ta en titt på var E2E-tester är placerade i programvarutestningspyramiden.
Platsen för E2E-tester i testpyramiden
När vi tittar på testpyramiden hittar vi fyra huvudsakliga testtyper som hjälper oss att garantera kodens kvalitet:
- E2E-tester hjälper till att verifiera högvärdiga vägar i din applikation. Med andra ord hjälper de till att verifiera användarberättelser eftersom de ofta representerar flöden i din applikation.
- Integrationstester hjälper till att verifiera integrationen av flera funktioner eller komponenter. Integrationstester kan tala om för dig om din kod fungerar sammanhängande med andra funktioner.
- Enhetstester hjälper till att verifiera funktionernas affärslogik. Enhetstester är den mest grundläggande formen av testning, och de säkerställer att affärslogiken är korrekt.
- Sist får vi inte glömma statisk analys eller statisk testning. Statisk testning hjälper till att hitta stavfel eller typfel.
Enligt denna pyramid bör de flesta tester vara enhetstester, med färre integrationstester och ännu färre E2E-tester. Det är dock fortfarande viktigt att verifiera flöden i din applikation. E2E-tester är svåra att underhålla och kräver mycket arbete. Verifiera därför endast de viktigaste flödena med E2E-tester. Andra testtyper som integrations- och enhetstester bör redan ge dig tillräckligt förtroende för din kodbas.
Olika E2E-teststrategier
Låt mig berätta att det finns olika strategier. Vi kan välja mellan horisontell E2E-testning och vertikal E2E-testning. Båda strategierna är värda att utforska eftersom de ger dig möjlighet att testa olika scenarier. Låt oss lära oss vad varje strategi gör.
Strategi #1: Vertikal End-to-End-testning
Denna strategi fokuserar på att testa alla lager i testpyramiden. Den omfattar enhetstester, integrationstester och UI-tester. Ditt mål är att testa en komponent på en granulär nivå med hjälp av enhetstester, testa hur en komponent beter sig när den interagerar med andra komponenter med hjälp av integrationstester och slutligen verifiera komponentens beteende när användare interagerar via användargränssnittet.
Det vanligaste är att du vill använda en pipeline för kontinuerlig integration för att automatisera dessa tester för varje kodöverföring eller pull request.
Strategi nr 2: Horisontell End-to-End-testning
Horisontell E2E-testning fokuserar på att verifiera ett komplett användarflöde. Här är ett exempel på ett flöde för en webbutik:
- Öppna produktsida
- Välj produktstorlek
- Lägg produkten i kundvagnen
- Gå till kassan
- Fyller adress- och betalningsinformation
- Fullbordar betalningen
- Visa köpbekräftelseskärm
Här vill vi verifiera varje transaktion i användarflödet. Ofta verifierar den här typen av testning interaktionen mellan olika program och verifierar tillståndsändringar för dessa program.
Bemärk att de här typerna av test är dyra att skriva. Det tar ganska lång tid att definiera användarflöden och skriva dessa tester. Försök därför att fokusera på kritiska transaktionsvägar för din applikation.
Se dock till att testa dessa kritiska användarflöden för olika förhållanden. Med denna strategi kan du få en fullständig bild av användarflödets robusthet. Dessa förhållanden inkluderar:
- Komplexa tidsscenarier: Till exempel är en konsertbiljett endast tillgänglig för dig i 15 minuter.
- Olika datainmatning eller saknade data.
- Flödesavbrott: En användare bestämmer sig för att lämna kassasidan för att titta på en annan produktsida. Vi måste till exempel kontrollera om komponenten sparar kassatillståndet.
Nästan ska vi lära oss när du ska skriva E2E-tester.
När du ska skriva E2E-tester
Du kanske inte vet att E2E-tester är dyra tester att köra i din pipeline för kontinuerlig integration. De kräver ofta en hel del förberedelser, till exempel skapandet av en databas som efterliknar produktionsdata. Dessutom representerar de ibland tidskrävande flöden i din applikation. Därför kan de vara långsamma och kräva mer resurser för att utföras.
Använd E2E-tester för att verifiera de viktigaste flödena i din applikation. Exempel på flöden med högt värde är:
- Inloggning och utloggning
- Registrera en ny användare
- Lägga till en vara i kundvagnen
- Ändra ditt lösenord
- Alla andra viktiga flöden som är relaterade till din tjänst
Gen glöm dock inte bort att verifiera den affärslogik som du skriver med enhets- och integrationstester. Kombinationen av både enhets- och integrationstester bör ge dig gott om förtroende för kvaliteten på din kod. E2E-tester hjälper dig att öka detta förtroende för kritiska vägar.
Här är några användbara tips för att skriva E2E-tester.
Tips för att skriva E2E-tester
Fokusera på att skriva återanvändbara tester
Det första och viktigaste tipset är att skriva små, oberoende, återanvändbara tester och komponenter. På så sätt kan du lättare sätta ihop flera små komponenter för att skapa kompletta användarflöden från början till slut. Istället för att skriva en massa anpassade komponenter som bara används av E2E-tester, fokusera på att skriva återanvändbara komponenter.
Att skriva små, oberoende komponenter underlättar återanvändning av kod och minskar tiden för felsökning. Det är också lättare att uppdatera små komponenter när funktionalitet eller användarflöden ändras.
Tänk alltid på anledningen till att skriva ett E2E-test
När du vill täcka ett visst flöde med ett E2E-test ska du överväga om det är värt att täcka. Testa endast högvärdiga användarflöden med E2E-tester. Du bör till exempel inte testa om ett felmeddelande visas när en användare matar in en felaktig e-postadress. Detta är ett alldeles för enkelt användningsfall som inte passar in i ett E2E-test. Detta krav kan helt enkelt testas med ett enhetstest.
Å andra sidan är det värt att testa om inloggningssidan omdirigerar dig till rätt applikationssida efter att du lyckats logga in. Detta är ett värdefullt flöde för att dina användare ska kunna använda applikationen. Kort sagt, tänk alltid på anledningen till att skriva ett E2E-test.
E2E-tester bör inte bero på implementeringsdetaljer
Du vill inte uppdatera E2E-testerna varje gång du ändrar implementeringsdetaljer för ett visst flöde. Därför vill du skriva komponenter som gör det möjligt att abstrahera implementeringsdetaljer. E2E-testning blir mycket enklare att underhålla och roligare att skriva när implementeringsdetaljerna döljs i komponenter. Kort sagt, E2E-tester bör vara oberoende av implementationsdetaljer.
Nästan ska vi titta på fallgroparna för E2E-tester.
Fallgropar för E2E-tester
Här är en lista över vanliga fallgropar som är förknippade med E2E-tester:
- E2E-tester bör inte försöka testa så mycket som möjligt på en gång. Ofta skriver utvecklare enorma E2E-tester som verifierar varje aspekt av användarflödet. Håll det enkelt och verifiera de viktigaste aspekterna av användarflödet. För ett inloggningsflöde behöver du till exempel bara verifiera om användaren omdirigerades till applikationssidan. Detta gör det lättare för utvecklare att underhålla och uppdatera E2E-tester.
- När ett E2E-test misslyckas kan det vara svårt att hitta den exakta orsaken till misslyckandet. Du kan dock minska de felsökningsinsatser som krävs genom att täcka din affärslogik med enhets- och integrationstester. Vissa verktyg ger också bra grundorsaksanalyser, inklusive skärmdumpar och konsolloggar av misslyckade teststeg, vilket kan minska tiden för felsökning.
- E2E-tester kräver en avsevärd mängd tid i din pipeline för kontinuerlig integration (CI). De kan blockera din CI-pipeline, vilket saktar ner den övergripande utvecklingen. Detta innebär att du kan behöva investera i din CI-pipeline för att ha några fler pipelines för att köra tester.
- E2E-tester är ett kontinuerligt arbete. Varje gång ny funktionalitet läggs till eller gammal funktionalitet ändras är det troligt att du måste uppdatera dina E2E-tester. Vi kan dock minska detta arbete genom att skriva återanvändbara komponenter som abstraherar implementeringsdetaljer. Dessutom använder vissa verktyg AI för att hjälpa till att anpassa testerna när koden ändras, vilket minskar testunderhållet.
Nu ska vi ta en kort titt på skillnaderna mellan systemtestning och E2E-testning.
Systemtestning vs. E2E-testning – vad är skillnaden?
Så, vad är skillnaden mellan systemtestning och E2E-testning? Systemtestning fokuserar på att validera både de funktionella som icke-funktionella kraven. Ofta utförs den av ett externt team som behandlar applikationen som en svart låda. Med andra ord vet de ingenting om hur applikationen fungerar förutom de krav som den ska uppfylla.
Denna form av testning förväxlas dock ofta med E2E-testning eftersom systemtestning är en form av E2E-testning. Systemtestning verifierar dock mycket mer än E2E-testning. Systemtestning mäter till exempel skalbarhet, prestanda eller tillförlitlighet. Medan E2E-testning fokuserar på korrekt utförande av användarflöden.
Sist sammanfattar vi lärdomarna från den här artikeln.
Slutsats om E2E
End-to-end-tester är ganska kraftfulla eftersom de hjälper till att validera högvärdiga användarflöden eller user stories. De hjälper till att garantera kvaliteten på din applikation.
Hur som helst kan det kräva mycket tid och ansträngning att skriva och underhålla E2E-tester. Det är möjligt att minska denna ansträngning genom att skriva små, återanvändbara komponenter som abstraherar implementeringsdetaljer. Vissa verktyg hjälper också till att skapa mer motståndskraftiga tester genom att använda AI eller flera attribut för att identifiera varje element. Därför behöver du inte uppdatera E2E-testerna varje gång implementeringsdetaljerna ändras för högvärdiga användarflöden. Dessutom kan du med hjälp av återanvändbara komponenter sätta ihop dessa komponenter för att enkelt skapa E2E-testflöden.
E2E-tester bör täcka de viktigaste flödena i din applikation. De testar de flöden som dina användare och kunder följer för att få värde från din applikation. Om de inte kan logga in eller lägga till en vara i en varukorg kommer de antingen att lämna (om de kan) eller ringa supporten om de är tvungna att använda din applikation. Du vill till exempel täcka flödet för inloggning och utloggning, men är mindre intresserad av att verifiera ett felmeddelande efter att ha angett en felaktig e-postadress.
I slutändan ska E2E-testerna vara roliga att skriva. De ska inte kräva mycket tid och ansträngning att skriva och underhålla. Håll E2E-testerna enkla och fokusera på återanvändbara komponenter, så kommer du att se bra resultat!
Detta inlägg skrevs av Michiel Mulders. Michiel är en passionerad blockchainutvecklare som älskar att skriva tekniskt innehåll. Dessutom älskar han att lära sig om marknadsföring, UX-psykologi och entreprenörskap. När han inte skriver, njuter han förmodligen av en belgisk öl!