Vad är automatiserad testning och CI/CD?
Överblick
När man arbetar med kod är det mycket som kan gå fel. Ändringar på ett ställe i koden kan förstöra helt andra delar av koden, ofta utan att man märker det. Att själv hålla koll på att alla delar av koden fortfarande fungerar efter att koden ändrats blir svårare och svårare ju större och mer komplex koden blir. Detta problem blir ännu tydligare när koden passeras mellan utvecklare, eller utvecklas av flera personer samtidigt, då alla inte längre har en full överblick över syftet av all kod. Om man inte implementerar något system för att kontrollera så att allt fortfarande fungerar efter man gjort ändringar är det lätt hänt att svårupptäckta buggar uppstår.
Ett sätt att lösa detta på är att prova så allt fungerar efter man gjort ändringar. Ifall man arbetar med en hemsida kan man till exempel skriva en lista av alla delar och funktioner på sidan samt hur de ska fungera. Därefter kan man gå igenom listan varje gång man gör ändringar, dvs. manuellt gå in på alla länkar och klicka på alla knappar m.m. Detta kallas för manuella tester. Problemet med denna lösning är att det tar väldigt mycket tid från arbetet, och är ofta väldigt tråkigt. Strukturerade manuella tester fungerar helt ok när man arbetar på något väldigt litet, men så fort projektet blir lite större är det inte längre rimligt att gå igenom och kolla allting själv på detta sätt.
Lösningen på detta är att använda automatiserade tester. Den enda skillnaden på manuella tester och automatiserade tester är att det istället är datorn som går igenom listan och kollar så att allting fungerar. Manuella tester utförs av utvecklaren, medan automatiserade tester utförs av datorn. Genom att skriva kod som går igenom och svarar på ifall hela produkten och alla dess delar fortfarande fungerar som de ska sparar man väldigt mycket tid och arbetskraft i längden. Risken för att buggar uppstår sänks också i och med att testerna kommer utföras med exakt samma noggrannhet och vara lika omfattande varje gång.
Med hjälp av automatiserade tester kan man...
- ...testa produkter mycket snabbare.
- ...testa produkter mycket mer precist och omfattande.
- ...testa större produkter mycket enklare.
- ...undvika att buggar dyker upp, speciellt de som annars inte skulle upptäckts på länge.
“Test Driven Development” (TDD)
Hur ska man då tänka och strukturera sitt arbete för att få in automatiserade tester i utvecklingsprocessen?
Man brukar tala om Test Driven Development (TDD, eller testdriven utveckling) och Red, Green, Refactor. I Test Driven Development skrivs testerna före mjukvaran, så att utvecklingsprocessen kan hjälpas av dem. I praktiken gör detta att fokuset av utvecklingen hamnar på kärndelarna hos produkten, och att det blir tydligt när alla delar hos produkten är klara. På detta sätt fungerar testerna lite som en interaktiv checklista, medveten om när produkten fungerar som den ska och checkar av sig själv. Denna metod att skriva tester först kan också hjälpa till att dela upp arbetsprocessen och produktens "checklista" i huvudet inför att man börjar skriva koden, då skrivandet av testet ofta tydliggör hur funktionen kommer behöva bli implementerad, och hur den kommer interagera med resten av mjukvaran.
"Red, Green, Refactor"
Mallen för denna filosofi kallas för "Red, Green, Refactor" och består av tre steg:
"Red"
Först skrivs det automatiserade testet, med syfte att kontrollera så att mjukvaran uppfyller ett visst krav eller att en specifik funktion fungerar som den ska. Steget heter "Red" eftersom testet ska misslyckas i detta steg, då funktionen ännu inte ska vara implementerad.
"Green"
Därefter skrivs kod med målet att få testet att lyckas. Man ska enligt denna arbetsfilosofi kunna lita på att testet är bra nog för att produkten ska vara fungerande när testet lyckas. Här läggs fokuset enbart på att testet ska lyckas, inte på att bra kod.
"Refactor"
När testet lyckas och produkten fungerar går man slutligen igenom och refaktoriserar koden. Här fokuserar man helt på att ta den fungerande produkten och finslipa den, med bekvämligheten att produkten redan fungerar som avsett. I detta steg uppmanas det även att gå igenom det automatiserade testet och kontrollera så att det är bra nog utifrån de lärdomar som gjorts under utvecklingsprocessen. Kontrollerar testet verkligen att produktens krav uppfylls? Finns det något man skulle kunna lägga till eller ändra för att göra testet mer träffsäkert?
Att följa alla dessa steg i samband med att man utvecklar en funktion kan verka som “overkill”, speciellt när man bara ska implementera något litet, men den säkerhet och struktur som denna arbetsprocess bidrar med förebygger att större och mer svårlösta problem dyker upp i framtiden. Syftet med dessa tester och TDD är att spara mycket tid i längden, även om det tar lite längre tid i stunden. Ifall det sker en ändring av produkten i framtiden som påverkar en tidigare funktion på något sätt, kommer testet för denna funktion berätta vad som är fel för utvecklaren och förhindra ändringen.
“Continuous Integration/Continuous Deployment” (CI/CD)
När man börjar arbeta med Continuous Integration, Continuous Delivery och Continuous Deployment blir automatiserade tester blir verkligen nödvändiga. CI/CD är en metod för att kunna leverera mjukvarubaserade produkter snabbt och ofta med hjälp av automatisering. I hjärtat av CI/CD finns ett mål av att automatisera så mycket som möjligt, speciellt alla processer relaterade till att integrera kod och leverera produkt. En av de största anledningarna att börja använda ett system för CI/CD är att automatisera sina tester. Mer specifikt att automatisera när och hur de tester man skrivit körs.
CI/CD som arbetsfilosofi förtjänar en helt egen guide, men om ni vill läsa mer nu har Red Hat ett jättebra sammanfattande artikel: https://www.redhat.com/en/topics/devops/what-is-ci-cd
Avslutande ord
Jag hoppas att ni har lärt er något mer om automatiserad testning i denna guide! Detta är en princip som, om den görs rätt, verkligen kan ta ens kodande till nästa nivå. Jag rekommenderar att prova göra några automatiserade tester för något projekt ni jobbar på, även om det är ett eget hobbyprojekt med bara något enstaka test.
Lycka till med kodandet och testandet! 👏🏻
Länkar
Jättebra verktyg för att automatisera testning av webbutvecklingsprojekt:
- “SeleniumHQ Browser Automation”, https://www.selenium.dev/
Lärorika föreläsningar om CI/CD och hur automatiserade tester används i praktiken på stora företag:
- “GOTO 2017 • It's Not Continuous Delivery If You Can't Deploy Right Now • Ken Mugrage - YouTube”, https://www.youtube.com/watch?v=po712VIZZ7M
- “Martin Fowler - Continuous Delivery - YouTube”, https://www.youtube.com/watch?v=aoMfbgF2D_4
Let's have a chat
Did you find anything especially interesting about this post, or do you have feedback to us? We are always open for discussion and eager to hear your thoughts and ideas!
Write us a comment to get in touch 👋🏼