Testning i Sverige: enhetstester, integrationstester och TDD i praktiken

Testning är en central del av professionell mjukvaruutveckling, och i svenska team är det en självklar del av arbetsflödet. Oavsett om man arbetar med startup eller storbolag förväntas man förstå skillnaden mellan enhetstester och integrationstester – och helst också ha koll på TDD. Den här lektionen ger dig en praktisk genomgång av hur testning ser ut i det svenska arbetslivet.

Varför testar vi?

Tester hjälper oss att säkerställa att koden gör vad vi förväntar oss – och att den fortsätter att göra det även när vi ändrar andra delar av systemet. En bra testsvit fungerar som ett skyddsnät: om du av misstag ändrar något som bryter befintlig funktionalitet, märker du det direkt istället för när en kund rapporterar ett fel.

I Sverige betonar många team en kultur av kvalitet. Kod som saknar tester accepteras sällan i en pull request, och kodtäckning (code coverage) är ett mått som ofta diskuteras i sprint reviews och retrospektiv.

Enhetstester – att testa en sak i taget

Ett enhetstest (unit test) testar en liten, isolerad del av koden – vanligtvis en enskild funktion eller metod. Tanken är att testet inte ska bero på externa system som databaser eller API:er. Istället använder man mocks eller stubs för att simulera dessa beroenden.

I JavaScript använder svenska team ofta Jest. I Python är pytest standard. I Java används JUnit. Gemensamt är att testerna körs snabbt och ger omedelbar feedback om något går fel.

Integrationstester – att testa hur delar samarbetar

Integrationstester går ett steg längre och testar hur flera delar av systemet fungerar tillsammans. Det kan handla om att kontrollera att en API-endpoint faktiskt sparar rätt data i databasen, eller att ett event korrekt triggar en notifikation.

Dessa tester är långsammare än enhetstester men fångar en annan typ av fel – de som uppstår i gränssnittet mellan komponenter. Svenska team brukar köra integrationstester som en del av CI-pipelinen, men separerat från enhetstesterna så att snabb feedback inte fördröjs.

Test-Driven Development (TDD) i praktiken

TDD är en metod där man skriver testet innan man skriver koden. Cykeln ser ut så här: skriv ett test som misslyckas (röd), skriv minsta möjliga kod för att testet ska passera (grön), förbättra koden utan att bryta testet (refaktorisera). Denna cykel kallas ofta för red-green-refactor.

I Sverige används TDD framför allt i team som arbetar med affärskritisk logik – till exempel betalningssystem, medicinsk mjukvara eller finansiella beräkningar. Metoden tvingar dig att tänka igenom kravspecifikationen innan du börjar koda, vilket leder till renare och mer väldefinierad kod.

Testpyramiden

Testpyramiden är en modell som hjälper team att balansera sina tester. Botten av pyramiden består av många, snabba enhetstester. Mitten innehåller färre integrationstester. Toppen har ett fåtal end-to-end-tester (E2E) som simulerar hur en riktig användare interagerar med systemet.

Många svenska team följer denna princip men anpassar den efter sin kontext. Ett team med ett renodlat REST-API kan lägga mer vikt vid integrationstester, medan ett team med komplex affärslogik prioriterar enhetstester.

Automatiserade tester i CI/CD

I moderna svenska DevOps-team körs alla tester automatiskt i en CI/CD-pipeline (Continuous Integration / Continuous Delivery). Vanliga verktyg är GitHub Actions, GitLab CI eller Bitbucket Pipelines. Testerna triggas automatiskt när någon pushar kod eller öppnar en pull request.

Om ett test misslyckas blockeras mergen tills problemet är löst. Det skapar ett bra skyddsnät och uppmuntrar teamet att hålla testsviten grön hela tiden.