Stubbning underlättar testning i stora testmiljöer

Vad är egentligen stubbning?

Stubbning handlar om att ta bort beroenden till externa system genom att ersätta de externa systemen med något som svarar på anrop och förfrågningar i dess ställe. Konceptet kallas även avintegrering eller de-coupling och för att åstadkomma detta använder man så kallade stubbar som svarar på anrop i stället för de riktiga kringliggande systemen.

Det är viktigt att testa sina API:er både utifrån konsument- och producentperspektivet. Det är oftast betydligt enklare att testa de API:er man är producent för eftersom det är lätt att använda ett verktyg som Postman eller ReadyAPI, eller något av alla webbläsar-plugins som finns för att testa REST-tjänster. Utmaningen kommer ofta när vi ska testa som konsument av ett externt API. Det är då vi måste stubba.

Varför stubba?

IT-landskapen har de senaste decennierna blivit alltmer komplexa. Många organisationer har tusentals IT-system och det blir allt svårare att genomföra kvalitetssäkringsaktiviteter i testmiljöer med alla system ihopkopplade med sammanhållet testdata.

Komplext organiskt nätverk av system

Även om man gör det djärva antagandet att fel inte propageras i flera led mellan system blir det ändå många kringsystem att få i rätt version och konfiguration och rätt testdata för att kunna genomföra ett test.

Om man använder integrerade testmiljöer till att avläsa sitt system får vi räkna med att även andra system gör detsamma. Det betyder att vi inte kan lita på något av de omkringliggande systemen heller i dessa miljöer. Förtroendet för våra testers resultat blir lågt.

Endast de närmsta kringliggande systemen

Genom att stubba de integrationer/samband vi behöver till andra system får vi kontroll över vår testmiljö. Vi får en lägre komplexitetsgrad och betydligt enklare att genomföra till negativa testfall.

Desto mer man kan testa av ett applikationssystem innan man behöver flytta det till en miljö med riktiga systemintegrationer, desto effektivare kvalitetssäkring blir det. Förutsättningarna för att automatisera tester i en fullt integrerad testmiljö är närmast obefintliga på grund av testdata-hanteringen, och ibland även på grund av autentiserings- och auktoriseringsmekanismer.

Stubbade samband

Stubbning vid testautomatisering

Att exekvera automatiserade tester konsumerar testdata. Vid scriptutveckling eller debugging är det besvärligt och tidskrävande att arbeta i testmiljöer där man måste tillrättalägga testdata i andra system än sitt eget. Det kan ibland bli övermäktigt att tillrättalägga testdata även i det system man faktiskt testar. Då kan man stubba bort databasen eller de externa systemen.

Typer av integrationstester

Man brukar kunna dela upp integrationstesterna i flera komponenter som kan utföras separat för klok effektivitet.

• System integration testing in the small: Systemintern test av komponentintegration (vertikal integration eller mellan komponenter).
• Samverkanstest: Uppfyller vi sambandskontraktet? Ursprungligen ett begrepp från telecom där man testar nätverksutrustning och telefoner mot gränssnitts-compliance innan de sätts in i riktigt nätverk där de riskerar störa annan utrustning.
• Sambandstest: Når vi fram till det externa systemets gränssnitt? En form av smoketest för att säkerställa att fortsatta tester är givande.
• Systemintegrationstest (system integration testing in the large): Kan vi genomföra verksamhetsprocesser end-2-end i fullt integrerad miljö och med produktionslikt data?

Att utföra alla typer av tester på de sista nivåerna blir hindrande för snabb time-to-market, försvårar debugging och felanalys och innebär att mycket testmöda och testtid läggs på testförberedelser snarare än testutförande.

Stubbning vs. mockning

Det råder en viss begreppsförvirring kring begreppen mockning och stubbning, och ibland kan uppdelningen kännas akademisk. Det är bra att veta att begreppen stundom används synonymt.

Mocking är det vanligaste alternativet till stubbning vid tidiga och utvecklarnära tester. Vid mockning byter man ut delar av programkoden mot annan kod som tjänar testet väl.

För mockning kan man exempelvis byta ut hela sin Authenticate-klass för BankId mot en annan som bara returnerar att man är autentiserad. Det finns massor av olika mockningsramverk och mockningshjälpmedel.

Mockade samband där man bytt ut delar av sin applikation för att komma åt att testa

Stubbning på enterprise-nivå: Service Virtualization

Åtskilliga leverantörer för testverktyg tillhandahåller även verktyg för Service Virtualization. Det är verktyg som hjälper till att underhålla och samordna stubbar för hela organisationer.

På liknande sätt finns det åtskilliga leverantörer av integrationsplattformar som tillhandahåller möjligheter till att virtualisera tjänster. I deras fall kallas det ofta för mockar eftersom de byter ut en del av programbeteendet i sin egen produkt (se definition ovan).

Dessa lösningar är ofta kompetenta men omgärdas av begränsningar eftersom de kräver licenser och specialistkunskap vilket gör att det alltid verkar bli linjefunktioner som managerar dessa, och ingen vill vänta på att tillrättalägga testdata så de blir oanvända.

Se vårt erbjudande

Vill du undvika krångel i testmiljöer och onödiga testförberedelser, och istället börja testa mer effektivt?

I guiden nedan har vi samlat våra bästa tips för dig som ska eller funderar på att komma igång med stubbning. Du får bland annat en introduktion till när stubbning är lämpligt, vilka för- och nackdelar som bör övervägas samt en kravlista för dig som vill hitta det perfekta stubbhjälpmedel.