Integrationstestning tillhör mittenlagret av testpyramiden, där testningen fokuserar på de delar av systemet där komponenter eller angränsande system kommunicerar med varandra. Denna kommunikation kan ske genom olika typer av meddelandetjänster, protokoll, informationsströmmar, m.m. som utgör integrationen mellan system.
Vad är integrationstestning?
Integrationstestning används för att kvalitetssäkra de integrationer som finns i ett system samt till angränsande system. Integrationstestning är en form av Black Box-testning, vilket betyder att koden som systemet uppbyggt av är okänd för testaren och endast de gränsytor systemet exponerar utåt kan användas för testning. Målet med integrationstestning är att se till att två system, eller komponenter av system, använder varandras gränsytor på rätt sätt och kan kommunicera med varandra.
Exempelvis kan en integration mellan två komponenter inom ett system bestå i att en komponent ansvarar för ett webbgränssnitt för att sälja produkter och en annan tjänst hanterar uppgifter om lagersaldo. Integrationstestning i detta exempel kan försöka säkerställa att den förstnämnda komponenten ställer korrekt formulerade frågor till lagertjänsten, och att svaren som erhålls tolkas på rätt sätt. Kort sagt, att komponenterna kan utbyta information mellan varandra.
Inom spannet för integrationstestning så kan man utföra tester som mer liknar system-test men också tester som ligger närmare enhetstesterna. På en högre nivå i testpyramiden kan flera komponenter och system kopplas ihop för att testa många integrationer tillsammans. I andra situationer passar det bättre bara testa en komponent i en isolerad miljö där integrationerna från kringliggande system simuleras. I de flesta fall är en blandning ett bra alternativ, där majoriteten av testningen sker på nivån som är närmare enhetstester och kompletterande testning kan fokusera på att testa stora flöden som involverar många integrationer.
Simulering och automation
Simulering och automation kan ge testaren mer kontroll, eftersom det är lättare att simulera att en integrerande komponent beter sig konstigt, än vad det är att få en komponent som är designad att fungera att bete sig på ett konstigt sätt. Det vill säga, simuleringen öppnar upp möjligheten att genomföra negativa testfall och kvalitetssäkra felhantering i större utsträckning.
Simulering och automation kan också vara användbart för att bygga bort testningens beroenden till de delar systemet eller komponenten under test integrerar mot. På så vis behöver inte testningen inom ett utvecklingsteam vänta på att ett annat team ska färdigställa den andra parten i en viss integration, eftersom dess beteende istället är simulerat i testmiljön.
För att möjliggöra simulering krävs testverktyg som har möjlighet att kommunicera med tjänsterna på det gränssnitt integrationen är implementerad över. Det kan antingen vara ett kommersiellt verktyg eller något som testaren implementerar i lämpligt programmeringsspråk.
I många testverktyg finns stöd för att skapa och använda s.k. testdubbletter (såsom mockar, stubbar och spioner). Dessa kan användas i ett testfall för att ersätta en komponent, metod eller klass med en fejkad dubblett, vilken har ett specifikt önskat beteende (t.ex., att alltid generera ett felmeddelande) eller har förmågan att “komma ihåg” hur den använts i testfallet, för att man på så sätt ska kunna verifiera att användningen skett korrekt.
API-testning
I många applikationer sker integration via API:er (t.ex. över HTTP) och ofta då med kollaboratörer som inte är kända på förhand. Allt fler myndigheter och organisationer erbjuder öppna API:er för att publicera sin data och även slutna produkter kan erbjuda API:er för att integrera mot andra produkter på marknaden. API-testning syftar till att troliggöra att systemet både kan göra det som utlovas av API:et men också att t.ex. det data som exponeras faktiskt är användbart för den som använder API:et.
Testningen utförs vanligen med hjälp av något slags verktyg, vilket kan vara automatiserat. Beroende på syftet med testningen kan det röra sig om enskilda API-anrop som testas i isolation, eller längre sekvenser med anrop som utgör eller blir en del av ett mer övergripande end-to-end-test.
En speciell teknik inom API-testning är kontraktstestning, där ett slags maskinläsligt kontrakt upprättas mellan tillhandahållaren av API:et å ena sidan och konsumenten av API:et å andra sidan. Typiskt innehåller kontraktet flera exempel på olika anrop med tillhörande svar och tanken är att tillhandahållaren då t.ex. inför en ny release kan verifiera att API:et fortfarande beter sig enligt kontraktet. Konsumenterna kan också använda kontraktet från sitt håll för att se att det anropande systemet faktiskt utför anropen enligt kontrakten och att svaren enligt exemplen tolkas korrekt.
Kontakta oss för konsultation eller frågor rörande tillgänglighetstestning
Har du frågor eller behöver hjälp med implementeringen av det tillgänglighetstestning? Tveka inte att höra av dig till oss. Fyll i formuläret så återkommer vi till dig inom kort. Vi finns här för att hjälpa dig att ta nästa steg i din digitala utveckling.
