Förbättra testtäckning och prestanda med testpyramiden

Att skriva automatiserade tester kan vara utmanande eftersom den här typen av kodning har sina särskilda förutsättningar. Om du planerar att använda dem i en DevOps-process för mjukvaruutveckling, med omfattande automatisering för både testning och infrastruktur som kod, är det viktigt att testerna körs snabbt och tillförlitligt. Otillförlitliga tester definieras på Google Testing Blog som: ”Flaky tests are tests that exhibit both a passing and a failing result with the same code”. Den typen av tester kan förstöra en pipeline, ge falska positiva resultat och få QA-teamet att dra fel slutsatser om testsvitens godkännandegrad.

UI-tester följer användarnas beteende, så att du kan verifiera funktionaliteten i hela mjukvaran ur användarnas perspektiv och därmed skapa konkret affärsvärde. Det skiljer sig från att till exempel testa om en funktion som genererar JSON har rätt format. Det är huvudpoängen i artikeln på Google Testing Blog, ”Just Say No to More End-to-End Tests”, som diskuterar de praktiska aspekterna av UI-testning. Där beskrivs UI-tester som opålitliga, svåra att hitta grundorsaken till och som att de döljer små fel bakom större fel, eftersom de flesta undantag undertrycks och endast anpassade varningar visas i UI:t.

För att underlätta ett skifte i detta synsätt presenterar Martin Fowler Test Pyramid, en bra visuell metafor som hjälper dig att tänka kring testningens olika lager och hur många tester som relativt sett ska fördelas på varje lager. Pyramiden nämndes först i Mike Cohns bok ”Succeeding with Agile”, men Martin menar att modellen är alltför förenklad och därför kan vara missvisande.

Låt oss titta på den moderna versionen av Test Pyramid, uppdaterad av Martin:

Pyramidens form är användbar för att visa två saker med detta arbetssätt: för det första hur många tester som bör implementeras på varje lager – längst ned finns fler tester än på de övre nivåerna. För det andra visar den resursanvändningen för att köra varje lager. Enhetstester längst ned körs snabbt och utan tredjepartsapplikationer, till skillnad från UI-tester högst upp, som använder en webbläsare och Selenium Server (till exempel). Fördelningen mellan kategorierna är helt i linje med dessa två mått. Låt oss fördjupa oss:

1. Enhetstester: Fokuserar på att testa den minsta funktionen i koden. Målet är att verifiera att funktionen kan ta emot indata och utföra den bearbetning som den har utformats för. Du kan mocka eller stubba indata för att göra testet oberoende av andra komponenter.

2. Komponenttester: Testar en hel komponent i mjukvaran, utan UI. Komponenten är en modul i applikationen. På den här nivån börjar testet verifiera affärsregler, eftersom alla mindre funktioner har testats på enhetstestnivån.

3. Integrationstester: Testar kommunikationen mellan två komponenter i arkitekturen. Målet är att verifiera att två komponenter kan kommunicera med varandra. Om komponenterna använder information från andra delar av systemet, till exempel API:er eller andra moduler, kan dessa mockas eller stubb as. Andra tester kan också ingå på den här nivån: kontraktstester, som verifierar att ett API följer sitt mönster, och konsumenttester, som verifierar att den del av koden som tar emot information från andra API:er kan använda den. Indata kan också mockas.

4. End-to-End: Testar hela mjukvaran via UI:t.

5. Utforskande/manuella tester: Vissa UI-tester är så komplexa att de kan vara svåra att automatisera och kan därför köras manuellt. Det finns också komplexa flöden som kan fångas upp med ett verktyg som analyserar applikationsloggar, till exempel Splunk, så att QA-teamet kan kartlägga dem och vidta åtgärder för att automatisera ett test.

6. Kontraktstest, som verifierar att ett API följer sitt mönster.

7. Konsumenttest, som verifierar att den del av koden som tar emot information från andra API:er kan använda den. Indata kan också mockas.

Enhetstester är enkla att skriva och köra till mycket låg kostnad. När du skriver dem bör du lägga tid på att verifiera funktionaliteten och avgränsa olika fall: om funktionen fungerar med förväntade indata och hur den hanterar oväntade eller ogiltiga indata. På komponenttestnivån är det dags att släppa de mindre funktioner som täcks av enhetstesterna och i stället verifiera mjukvarans affärsregler.

För integrationstester måste täckningen gå längre än de förväntade fallen i kommunikationen mellan komponenterna. Testerna behöver kunna förstå en komponents felmeddelanden och när undantag ska returneras så att applikationen kan hantera dem. Glöm inte att stubba eller mocka det som inte testas inom detta område. Om du till exempel testar databaskommunikation behöver du inte anropa riktiga tredjeparts-API:er.

End-to-End-tester måste testa de viktigaste användarflödena i applikationen. De bör vara färre än de tidigare testerna eftersom de redan täcker stora delar av applikationen. Det finns ingen anledning att duplicera tester.

Avslutningsvis:

Att testa applikationer enbart med UI-tester medför stora långsiktiga kostnader och skapar osäkerhet på grund av deras opålitlighet. Test Pyramid är en bra metod för din DevOps-process för mjukvaruutveckling eftersom den kostar mindre och är snabb och tillförlitlig.