Något det ofta pratas om, kanske framför allt kopplat till testautomatisering är enhets- och integrationstester. Men vad innebär dessa tester i praktiken och hur används de? Det går jag igenom i det här blogginlägget!
Enhetstester testar att de minsta enheterna i en applikation fungerar som det är tänkt. Dessa tester har ett starkt förhållande till den faktiska implementationen, snarare än att verifiera om ett system fungerar som det är tänkt utifrån ett verksamhetsperspektiv. Vid testdriven utveckling används enhetstester för att definiera hur en enhet ska formuleras och verifierar att givna inparametrar och utgångsförhållanden ger korrekt resultat. Istället för att skriva produktionskod först och enhetstester efter, så skrivs enhetstester först som naturligtvis varken fungerar att köra eller som visar korrekt resultat. Utifrån det läget låter man sedan produktionskoden växa fram genom att skapa det som behövs för att enhetstestet ska lyckas. Enhetstestning bör snarare ses som ett viktigt komplement under utveckling, än en testtyp tillräcklig för att verifiera rätt kvalitet.
Integrationstest testar att alla enheter i en applikation fungerar tillsammans. I dessa tester kan applikationen anropas utifrån så som den är tänkt att användas av användaren eller andra system. Detta gör att dem inte sitter ihop med lösningen på samma sätt som enhetstester, och behöver därigenom inte påverkas i lika stor utsträckning och lösningen, till exempel refaktoreras. Integrationstester är perfekta för regressionstestning och kan byggas för att hitta buggar så tidigt som möjligt. En förutsättning för dessa tester är att man belyser testbarheten i applikationen. Hur autentiserar man sig mot en applikation som ska integrationstestas, och hur är det med applikationskonfiguration om tjänsten ska testas lokalt på en arbetsdator?
Låt oss göra en enkel liknelse:
En intern enhet i en applikation kan liknas med en del under huven på din bil, till exempel fläktremmen. För att säkerställa fläktremmens kvalitet kommer den att testas för sig, där saker som hållfasthet, livslängd och friktion i materialet kontrolleras. Dock är det inte viktigt för föraren att det finns en fläktrem i bilen, utan snarare att bilen som helhet är robust, och därigenom behöver en fungerande kylning av motorn. Skulle biltillverkaren utveckla en helt ny metod att kyla ner motorn på, skulle visserligen de interna testerna för att testa fläktremmar bli oanvändbara, men testerna av bilen utifrån ett förarperspektiv skulle vara oförändrade. Man skulle med fördel kunna använda samma förarbaserade tester för att bedöma att bilen kör lika bra eller bättre med den uppdaterade kylningen.
Även fast syftet med enhets och integrationstestning är olika, så kan dem med fördel ofta byggas med samma tekniker. Enhetstester behöver utifrån sin natur vara skrivna i samma programmeringsspråk som koden som testas för att få ut maximalt av effekten. Detta hjälper oss att hitta kompileringsfel som en följd av en uppdatering, vilket gör att återkopplingen blir så snabb som möjligt. Dessa tester har sällan eller få beroenden till infrastruktur, och är därigenom befriade från utmaningar runt testmiljöer, testdata och beroenden till andra system. Något som gör enhetstester till den mest pålitliga testtypen.
Genom att använda rätt verktyg kan man i många fall få samma goda fördelar för integrationstester. Här kommer man behöva förutsättningar för att anropa applikationen utifrån och igenom, där rätt klientstöd och mockningsteknik behöver användas. Det är också vanligt att man kan behöva exekvera hela applikationen så som den är tänkt för att komma åt hela teknikstacken.
Enhetstestning och Integrationstestning är två viktiga förutsättningar för att utveckla mjukvara med rätt kvalitet. Tillsammans formar dem de tidigaste automatiska testerna som är absoluta förutsättningar för att kunna leverera ny mjukvara i hög frekvens på kort tid. Genom rätt verktygsval kommer du få en hög tilltro till dessa tester. Dem kommer ge stöd vid nyutveckling och en berättigad känsla av kvalitet vid förändringar.