RESTful testning på Let’s test 2016

with No Comments

RESTful testing har blivit ett hett begrepp på senare tid, men vad menar man egentligen med RESTful och hur kan man tillämpa det i praktiken?

På konferensen Let’s Test i Stockholm så fick vi möjligheten att delta på en 4-timmars workshop på ämnet. Workshopen leddes av Mark Winteringham. Mark har arbetat mycket med testautomatisering och har ca 8 års erfarenhet som testare. Vi fick utmaningen att testa Marks webbtjänst där han hade kodat in buggar som vi skulle hitta och rapportera.

 

27207613116_4f6c670f7e_k
                                                                                                                                                                               Foto: Martin Nilsson, House of Test

Vad är RESTful? 

När man pratar om REST-test, så är det rent generellt API-tester man syftar till. Ett API kan enkelt förklaras som ett kommunikationsgränssnitt mellan olika tjänster, t.ex. en webbtjänst och ett användargränssnitt. REST är en arkitekturstil, eller riktlinjer för hur man bör skriva sitt API, och är den vanligaste typen av API som används inom dagens webbtjänster. Att testa direkt mot ett API innebär att man skickar requests via HTTP mot webtjänstens API, istället för att gå via ett användargränssnitt.

En term som ofta dyker upp när man pratar om API och HTTP är CRUD, och representerar de fyra huvudfunktionerna hos ett HTTP protokoll: Create, Read, Update och Delete. Dessa är typiska funktioner att inkludera i sina tester.

Förutom att vara en stark del i utforskande tester, kan API testning med fördel göras med hjälp av automatiserade tester. En stor anledning att arbeta direkt mot ett API istället för ett GUI när man bygger automatiserade tester, är att testerna inte är beroende av att gränssnittet förändras. Här spelar det ingen roll om knappar och textfält flyttas eller döps om. API-tester är också fördelaktiga då de är relativt enkla att skriva och underhålla jämfört med tex GUI-tester.

 

Postman

Det finns gott om verktyg för att underlätta API testning. Under workshopen använde vi oss av ett tillägg till Chrome som heter Postman. Till skillnad ifrån andra verktyg var Postman väldigt enkelt att komma igång med. Via gränssnittet i Postman får man hjälp med hur olika typer av requests kan skrivas, och vilka egenskaper de skall ha. Postman har också stöd för autentisering, dels genom cookies med också via BASIC authentication. Postman erbjuder möjligheten att skapa egna testsviter där man kan spara sina request och sedan köra hela sviter med testfall.

 

PutWithAuth

 

Våra tankar under och efter workshopen  

Vi kom till workshopen med ganska lite erfarenhet av API-testning. Vi hade ca två veckor innan utforskat ett annat verktyg för API-testning som heter SoapUI. Fyra gånger per år har vi på Nethouse något vi kallar för Braindays. Detta är dagar då vi får möjlighet, och uppmuntras att ta en heldag för att utforska nya tekniker och lära oss nya saker. Under en Brainday i våras passade några ur testgruppen på att titta på SoapUI. Vi ville utvärdera om, och hur, det kunde användas i våra projekt för att hjälpa oss med automatiserade tester. Ingen av deltagarna hade speciellt mycket erfarenhet av API-testning, och det ledde till att vi inte kom riktigt så långt som vi önskade. Det vi behövde var en bra introduktion, och därför kändes det perfekt med en workshop om just RESTful testing!

Mark började med att gå igenom de teoretiska grunderna med API-testning och varför det är viktigt att utvärdera om det kan tillföra värde i testprocessen. Innan de praktiska övningarna fick vi konkreta exempel på hur man kan ”tänka CRUD” för att läsa och manipulera data med hjälp av Postman mot sin webbtjänst. Workshopen var indelad i fyra avsnitt, en för varje område. Varje del inleddes med en teoretisk genomgång, följt av ungefär 15 minuter då vi fick laborera mot webbtjänsten och avslutades med en avstämning med hela gruppen där vi fick dela med oss om eventuella fel och frågor vi hittade.

API-tester känns som ett bra komplement till utforskande tester och kan vara ett enkelt och kraftfullt sätt att få igång några grundläggande automatiserade tester. En annan styrka vi såg var att man snabbt kan generera testdata direkt via ett API istället för att skapa testdata genom gränssnittet.

Vi märkte ganska tidigt att Postman var mycket enklare att komma igång med jämfört med SoapUI, lätt att installera och med ett intuitivt gränssnitt. En annan styrka med verktyget var också hur enkelt vi kunde göra automatiska verifieringar på våra requests för att säkerställa att data motsvarade förväntat resultat. Även om vårt intryck av Postman var bra så finns det fortfarande en del frågor som återstår och som vi aldrig hann utforska, t ex hur verktyget fungerar på stora webbtjänster, då vi endast testade mot en relativt enkel och liten tjänst.

Vi kände efter workshoppen att vi fick upp ögonen för hur mycket API-testning ger och kommer under hösten definitivt se över möjligheten att tillämpa det i våra projekt.

 

Hittade vi buggarna Mark gömt då? Jajamen, och vi hade skoj under tiden!

Follow patrik.d.johansson:

Latest posts from

Leave a Reply