streamalism.org

1. Introduktion

For grundigt at teste en web-API har vi brug for en slags webklient for at få adgang til API's slutpunkter. Postbrevet er et enkeltstående værktøj, der udøver web-API'er ved at fremsætte HTTP-anmodninger uden for tjenesten.

Når vi bruger Postman, behøver vi ikke skrive nogen HTTP-klientinfrastrukturkode kun for testens skyld. I stedet opretter vi testpakker kaldet samlinger og lader Postmand interagere med vores API.

I denne vejledning ser vi, hvordan man opretter en Postman Collection, der kan teste en REST API.

2. Opsætning

Før vi kommer i gang med vores samling, skal vi indstille miljøet.

2.1. Installation af postbud

Postman er tilgængelig til Linux, Mac og Windows. Værktøjet kan downloades og installeres fra Postmans hjemmeside.

Efter at have afvist stænkskærmen kan vi se brugergrænsefladen:

2.2. Kørsel af serveren

Postbud har brug for en live HTTP-server til at behandle sine anmodninger. Til denne tutorial bruger vi et tidligere Baeldung-projekt, spring-boot-rest, som er tilgængelig på GitHub.

Som vi måske gætter ud fra titlen, fjeder-støvle-hvile er en Spring Boot-applikation. Vi bygger appen med Maven-målet installere. Når vi er bygget, starter vi serveren med det tilpassede Maven-mål spring-boot: løb.

For at bekræfte, at serveren kører, kan vi trykke på denne URL i vores browser:

// localhost: 8082 / spring-boot-rest / auth / foos

Denne tjeneste bruger en in-memory database. Alle poster slettes, når serveren stoppes.

3. Oprettelse af en postbudssamling

En samling i Postbrevet er en række HTTP-anmodninger. Postbud gemmer alle aspekter af anmodningerne, inklusive overskrifter og meddelelsesorganer. Derfor, vi kan køre anmodningerne i rækkefølge som semi-automatiserede tests.

Lad os begynde med at oprette en ny samling. Vi kan klikke på rullemenupilen på Ny og vælg Kollektion:

Når Opret en ny samling dialog vises, kan vi navngive vores samling “foo API test“. Endelig klikker vi på skab knappen for at se vores nye samling vises på listen til venstre:

Når vores samling er oprettet, kan vi holde markøren over den for at afsløre to menuknapper. Pileknappen åbner et træk-højre panel, der giver adgang til Collection Runner. Omvendt åbner ellipseknappen en rullemenu, der indeholder en række handlinger på samlingen.

4. Tilføjelse af en POST-anmodning

4.1. Oprettelse af en ny anmodning

Nu hvor vi har en tom samling, lad os tilføje en anmodning, der rammer vores API. Lad os specifikt sende en POST-besked til URI / auth / foos. At gøre det, vi åbner ellipsemenuen i vores samling og vælger Tilføj anmodning.

Når GEM ANMODNING dialog vises, lad os give et beskrivende navn, såsom “Tilføj en foo ”. Klik derefter på knappen Gem til foo API-test.

Når anmodningen er oprettet, kan vi se, at vores samling angiver en anmodning. Men hvis vores samling ikke er blevet udvidet, kan vi ikke se anmodningen endnu. I så fald kan vi klikke på samlingen for at udvide den.

Nu skal vi se den nye anmodning opført under vores samling. Vi kan se, at den nye anmodning som standard er en HTTP GET, hvilket ikke er det, vi ønsker. Vi løser det i næste afsnit:

4.2. Redigering af anmodningen

Lad os klikke på den for at redigere anmodningen og indlæse den på fanen for anmodningseditor:

Selvom anmodningseditoren har adskillige muligheder, har vi kun brug for nogle få af dem indtil videre.

Lad os for det første bruge rullemenuen til at ændre metoden fra GET til POST.

For det andet har vi brug for en URL. Til højre for metoden er et tekstfelt til anmodnings-URL'en. Så lad os indtaste det nu:

// localhost: 8082 / spring-boot-rest / auth / foos

Det sidste trin er at give en meddelelsesdel. Under URL-adressen er der en række faneblade. Vi klikker på Legeme faneoverskrift for at komme til body editor.

I Legeme fanen lige over tekstområdet er der en række radioknapper og en rullemenu. Disse styrer formateringen og indholdet af anmodningen.

Vores service accepterer JSON-data, så vi vælger rå Radio knap. I rullemenuen til højre anvender vi JSON (applikation / json) indholdstype.

Når kodningen og indholdstypen er indstillet, tilføjer vi vores JSON-indhold til tekstområdet:

{"name": "Transformers"}

Lad os endelig gemme vores ændringer ved at trykke på Ctrl-S eller rammer Gemme knap. Det Gemme knappen er placeret til højre for Sende knap. Når vi har gemt, kan vi se, at anmodningen er opdateret til POST i listen til venstre:

5. Kørsel af anmodningen

5.1. Kørsel af en enkelt anmodning

For at køre en enkelt anmodning skal vi bare klikke på Sende knap til højre for URL-adressen. Når vi klikker Sende, svarpanelet åbnes under anmodningspanelet. Det kan være nødvendigt at rulle ned for at se det:

Lad os undersøge vores resultater. Specifikt i overskriftslinjen ser vi, at vores anmodning lykkedes med status 201 Oprettet. Desuden viser reaktionsorganet, at vores Transformere rekord modtaget id på 1.

5.2. Brug af Collection Runner

I modsætning til Sende knappen, kan samlingsløberen udføre en hel samling. For at starte samlingsløberen holder vi markøren over vores foo API test samling, og klik på pilen til højre. I træk-højre panel kan vi se a Løb knappen, så lad os klikke på det:

Når vi klikker på Løb -knappen indsamlingsløber åbnes i nyt vindue. Fordi vi lancerede det fra vores samling, er løberen allerede initialiseret til vores samling:

Samlingsløberen tilbyder muligheder, der påvirker testkørslen, men vi har ikke brug for dem til denne øvelse. Lad os gå direkte til Kør foo API test knappen nederst og klik på den.

Når vi kører samlingen, ændres visningen til Kør resultater. I denne opfattelse vi ser en liste over tests, der er markeret med grøn for succes og rød for fiasko.

Selvom vores anmodning blev sendt, angiver løberen, at der var bestået nul test og nul test mislykkedes. Dette skyldes, at vi endnu ikke har tilføjet tests til vores anmodning:

6. Test af svaret

6.1. Tilføjelse af test til en anmodning

For at oprette en test, lad os vende tilbage til anmodningsredigeringspanelet, hvor vi byggede vores POST-metode. Vi klikker på Test fane, der er placeret under URL'en. Når vi gør det, vises testpanelet:

I panelet Tests skriver vi JavaScript, der udføres, når svaret modtages fra serveren.

Postman tilbyder indbyggede variabler, der giver adgang til anmodningen og svaret. Desuden kan et antal JavaScript-biblioteker importeres ved hjælp af kræve() syntaks.

Der er alt for mange scriptfunktioner til at dække i denne vejledning. Imidlertid er den officielle postbudtendokumentation en fremragende ressource om dette emne.

Lad os fortsætte med at tilføje tre tests til vores anmodning:

pm.test ("successtatus", () => pm.response.to.be.success); pm.test ("navn er korrekt", () => pm.expect (pm.response.json (). navn) .to.equal ("Transformers")); pm.test ("id blev tildelt", () => pm.expect (pm.response.json (). id) .to.be.not.null);

Som vi kan se, disse tests gør brug af det globale om eftermiddagen modul leveret af Postman. Især bruger testene pm.test (), pm.expect ()og pm.svar.

Det pm.test () funktion accepterer en etiket og en påstandsfunktion, såsom forventer(). Vi bruger pm.expect () at hævde betingelser for indholdet af svaret JSON.

Det pm.svar objekt giver adgang til forskellige egenskaber og operationer på svaret, der returneres fra serveren. Tilgængelige egenskaber inkluderer blandt andet svarstatus og JSON-indhold.

Som altid gemmer vi vores ændringer med Ctrl-S eller den Gemme knap.

6.2. Kørsel af testene

Nu hvor vi har vores tests, lad os køre anmodningen igen. Ved at trykke på Sende -knappen viser resultaterne i Test resultater fanen i svarpanelet:

Ligeledes viser samlingsløberen nu vores testresultater. Specifikt viser resuméet øverst til venstre det opdaterede bestået og mislykkedes totaler. Nedenfor resumeet er en liste, der viser hver test med dens status:

6.3. Visning af postbudskonsollen

Det Postbudskonsol er et nyttigt værktøj til oprettelse og fejlretning af scripts. Vi kan finde konsollen under Udsigt menu med elementnavnet Vis postbudskonsol. Når den startes, åbnes konsollen i et nyt vindue.

Mens konsollen er åben, registrerer den alle HTTP-anmodninger og svar. Desuden, når man bruger scripts console.log (), det Postbudskonsol viser disse meddelelser:

7. Oprettelse af en rækkefølge af anmodninger

Indtil videre har vi fokuseret på en enkelt HTTP-anmodning. Lad os nu se, hvad vi kan gøre med flere anmodninger. Ved at kæde en række anmodninger sammen kan vi simulere og teste en klient-server-workflow.

Lad os i dette afsnit anvende det, vi har lært for at oprette en række anmodninger. Specifikt tilføjer vi tre yderligere anmodninger om at udføre efter den POST-anmodning, vi allerede har oprettet. Disse bliver en GET, en DELETE og endelig en anden GET.

7.1. Indfangning af svarværdier i variabler

Før vi opretter vores nye anmodninger, lad os foretage en ændring af vores eksisterende POST-anmodning. Fordi vi ikke ved, hvilket id serveren tildeler hver foo For eksempel kan vi bruge en variabel til at registrere det id, der returneres af serveren.

For at indfange det id tilføjer vi endnu en linje i slutningen af ​​POST-anmodningens testscript:

pm.variables.set ("id", pm.response.json (). id);

Det pm.variables.set () funktion tager en værdi og tildeler den til en midlertidig variabel. I dette tilfælde opretter vi en id variabel til at gemme vores objekts id-værdi. Når det er indstillet, kan vi få adgang til denne variabel i senere anmodninger.

7.2. Tilføjelse af en GET-anmodning

Brug nu teknikkerne fra tidligere sektioner til at tilføje en GET-anmodning efter POST-anmodningen.

Med denne GET-anmodning henter vi det samme foo eksempel, at POST-anmodningen blev oprettet. Lad os navngive denne GET-anmodning som “få en foo“.

URL'en til GET-anmodningen er:

// localhost: 8082 / spring-boot-rest / auth / foos / {{id}}

I denne URL henviser vi til id variabel, som vi tidligere har indstillet under POST-anmodningen. Således skal GET-anmodningen hente den samme forekomst, som blev oprettet af POST.

Når der vises variabler uden for scripts, henvises der til ved hjælp af syntaksen med dobbeltbøjle {{id}}.

Da der ikke er nogen instans til en GET-anmodning, lad os gå direkte til Test fanen. Da testene er ens, kan vi kopiere testene fra POST-anmodningen og derefter foretage et par ændringer.

For det første, vi behøver ikke at indstille id variabel igen, så lad os ikke kopiere den linje.

For det andet ved vi, hvilket id vi kan forvente denne gang, så lad os kontrollere det id. Vi kan bruge id variabel for at gøre det:

pm.test ("successtatus", () => pm.response.to.be.success); pm.test ("navn er korrekt", () => pm.expect (pm.response.json (). navn) .to.equal ("Transformers")); pm.test ("id er korrekt", () => pm.expect (pm.response.json (). id) .to.equal (pm.variables.get ("id")));

Da dobbeltstivningssyntaxen ikke er gyldig JavaScript, bruger vi pm.variables.get () funktion for at få adgang til id variabel.

Lad os endelig gemme ændringerne, som vi har gjort før.

7.3. Tilføjelse af en SLET anmodning

Dernæst tilføjer vi en SLET anmodning, der fjerner foo objekt fra serveren.

Vi fortsætter med at tilføje en ny anmodning efter GET og indstille dens metode til SLET. Vi kan navngive denne anmodning “slet en foo“.

URL'en til sletningen er identisk med GET URL:

// localhost: 8082 / spring-boot-rest / auth / foos / {{id}}

Svaret har ikke et organ til at teste, men vi kan teste svarkoden. Derfor vil DELETE-anmodningen kun have en test:

pm.test ("successtatus", () => pm.response.to.be.success);

7.4. Bekræftelse af SLET

Lad os endelig tilføje endnu en kopi af GET-anmodningen for at kontrollere, at DELETE virkelig virkede. Lad os denne gang duplikere vores første GET-anmodning i stedet for at oprette en anmodning fra bunden.

For at duplikere en anmodning højreklikker vi på anmodningen for at få vist rullemenuen. Derefter vælger vi Duplikere.

Den dobbelte anmodning har ordet Kopi vedhæftet sit navn. Lad os omdøbe det til “bekræft sletning”For at undgå forvirring. Det Omdøb mulighed er tilgængelig ved at højreklikke på anmodningen.

Som standard vises den dobbelte anmodning umiddelbart efter den oprindelige anmodning. Som et resultat bliver vi nødt til at trække det under DELETE-anmodningen.

Det sidste trin er at ændre testene. Men inden vi gør det, lad os benytte lejligheden til at se en mislykket test.

Vi har kopieret GET-anmodningen og flyttet den efter SLETNINGEN, men vi har ikke opdateret testene endnu. Da DELETE-anmodningen skulle have slettet objektet, skulle testene mislykkes.

Lad os sørge for at gemme alle vores anmodninger og derefter trykke på Prøve igen i samlingsløberen. Som forventet mislykkedes vores tests:

Nu hvor vores korte omvej er afsluttet, lad os rette testene.

Ved at gennemgå de mislykkede tests kan vi se, at serveren reagerer med en 500-status. Derfor ændrer vi status i vores test.

Desuden ved at se det mislykkede svar i Postbudskonsol, lærer vi, at svaret inkluderer en årsag ejendom. Desuden er årsag egenskab indeholder strengen “Ingen værdi til stede“. Vi kan også teste for det:

pm.test ("status er 500", () => pm.respons.til.har.status (500)); pm.test ("ingen værdi til stede", () => pm.expect (pm.response.json (). årsag) .to.equal ("Ingen værdi til stede"));

7.5. Kører hele samlingen

Nu hvor vi har tilføjet alle anmodningerne, lad os køre den fulde samling i samlingsløberen:

Hvis alt er gået efter planen, skal vi have ni vellykkede tests.

8. Eksport og import af samlingen

Mens Postbud gemmer vores samlinger på et privat, lokalt sted, vil vi måske dele samlingen. For at gøre det eksporterer vi samlingen til en JSON-fil.

Det Eksport kommandoen er tilgængelig i samlingens ellipsemenu. Når vi bliver bedt om en JSON-filversion, lad os vælge den senest anbefalede version.

Når vi har valgt filversionen, vil Postman bede om et filnavn og en placering til den eksporterede samling. Vi kan f.eks. Vælge en mappe inden for vores GitHub-projekt.

For at importere en tidligere eksporteret samling bruger vi Importere knap. Vi kan finde det i værktøjslinjen i hovedbilledvinduet. Når Postbeder beder om en filplacering, kan vi navigere til den JSON-fil, vi ønsker at importere.

Det er værd at bemærke, at Postman ikke sporer eksporterede filer. Som et resultat viser Postman ikke eksterne ændringer, før vi genimporterer samlingen.

9. Konklusion

I denne artikel har vi brugt Postman til at oprette semi-automatiserede tests til en REST API. Mens denne artikel fungerer som en introduktion til Postmans grundlæggende funktioner, har vi næppe ridset overfladen af ​​dens evner. Postbanks online dokumentation er en værdifuld ressource til dybere udforskning.

Samlingen oprettet i denne vejledning er tilgængelig på GitHub.