Konsumentdrivna kontrakt – det etthundraförsta sättet att testa din applikation

25 juni 2019

Manuell testning, automatiseringstestning, unit-tester, frontend-tester, prestandatester och säkerhetstester. Test, test och åter test. Googlar du ”types of software testing” så kommer en lista med inte mindre än 100 olika testtyper upp, alla med ett gemensamt mål; att validera en applikation under test (Application Under Test, AUT). Så hur vet du vilket sätt du ska använda i testdjungeln?

Jag heter Felipe Otarola och jobbar med QA/testutveckling på Forefront. I denna artikel kommer jag berätta om det etthundraförsta (101) sättet att kvalitetssäkra mjukvara, nämligen genom Konsumentdrivna kontrakt (Consumer driven contracts, CDC).

Fördelarna med mikrotjänster – Varför ska du använda CDC?

Konsumentdrivna kontrakt är en modell för att specificera och verifiera interaktioner mellan olika moduler i en applikation. Konsumentdriven innebär att det är mottagarens ansvar att ange vilka interaktioner den är beroende av, liksom dess format. Övriga tjänster måste i sin tur komma överens om dessa kontrakt och se till att de inte bryter dem.

 

Konsumentdrivna kontakt är egentligen ingenting nytt, men har ökat i popularitet sedan allt fler företag väljer att bygga sina applikationer på ett distribuerat sätt och då oftast genom mikrotjänster. Mikrotjänstarkitektur bygger på att splittra applikationen till små fristående tjänster där varje tjänst har sin unika roll i systemet. Tjänsterna är då frikopplade under samma körning och ändringar i gränssnittet fångas inte längre av kompilatorn.

 

Anta att systemet (se bild längst ned) är uppbyggt av flera mikrotjänster. Det finns fler sätt som dessa interaktioner kan brytas genom förändringar i de olika tjänsterna. Ett vanligt sätt skulle vara att sändaren/leverantören skulle ändra dess gränssnitt på ett sådant sätt att mottagaren/konsumenten inte längre kan interagera med den.

  • Ändringar i slutpunkten (GET /events/ till GET /event/)

  • Ändringar i de förväntade parametrarna (GET /events får ett nytt fält)

  • Ändringar i svaret från systemet (returnerar en lista istället för att ha en uppdelad lista i objektet)

Även om exemplen är typiska API-brytare, så kan de vara mindre självklart att små förändringar i koden kan ändra strukturen i svaret från systemet. Dessa ändringar skulle ha fångats i en monolitisk applikation men eftersom den nu är uppdelad i fler tjänster så fångas de inte upp vid en kompilering. Systemet förstår inte att det finns fel. 

Hur fungerar konsumentdrivna kontrakt?

Alla tjänster kommunicerar med ett RESTAPI vilket betyder att vi kan definiera ett kontrakt mellan API:erna och att vi inte behöver spinna upp hela plattformen.
Det finns två typer av peers – en klient och en leverantör. Utvecklarna behöver bekräfta att dessa är kompatibla med varandra och vi behöver därför definiera API-kontraktet på klientsidan. Konsumenten är en klient som vill ta emot data från en annan tjänst. Man definierar krav mot API:et med till exempel: Headers, Statuskoder, Payload och Responses. Efter att alla tester har exekverats skapas en JSON-fil som innehåller information om http request.

Hur testar vi?

Mikrotjänster har inte bara förändrat mjukvarans arkitektur utan också hur vi testar den. Så hur säkerställer vi att alla tjänster fungerar tillsammans? Som vi tog upp tidigare är det rätt enkelt att testa en monolitisk applikation. Appen har en kodbas och behöver inte förlita sig på externa tjänster. Helt i kontrast mot en distribuerad tjänst som är beroende av informationen som kommer från olika tjänster. Detta innebär att man måste hitta sätt att verifiera att tjänsterna skickar korrekt information. Ofta så väljer man att bygga miljön och alla tjänster startas upp innan man kan börja testa. Detta kan dock bli både ineffektivt och dyrt. 

Dela kontrakt mellan leverantören och konsumenten

När konsumenttesterna har passerat och JSON filen med kontraktet har skapats så är det konsumentens ansvar att leverera kontraktet till leverantören.

 

Detta kan göras på olika sätt:

  • Maila filen direkt till konsumenten

  • Git repository för pactfilerna som varje part har tillgång till

  • Gemensamt filsystem...

  • ... samt Pact Broker. Pact Broker är en applikation för att dela konsumentkontrakt och verifieringar. Konsumenten pushar kontraktet och tillåter leverantören att ladda ner dem och köra mot sina tester.

Att testa mikrotjänster är fortfarande ett komplext moment. Men slipper vi starta upp flera tjänster och beroenden än som behövs så sparar vi tid. Slutningen bör testning genom konsumentdrivna kontakt inte ersätta ett klassiskt end-to-end test, vi kan dock kombinera de två för att öka testets täckning.

 

Vill du lära dig mer? Hacka loss med pacts repository

 

Vill du veta hur ditt företag kan komma igång med test eller söker du jobb inom test?

Kontakta Reyhan Kabacaoglu, New Business Manager på Forefront Consulting

 

Kolla också in följande jobbannonser:

Teknisk testare/testautomatiserare

Testledare/QA

 

Nästa nyhet

Grattis till traineerna i Generation 6, som nu tagit examen från Forefronts traineeprogram!

20 juni 2019