streamalism.org

1. Introduksjon

For å teste en web-API grundig, trenger vi en slags nettklient for å få tilgang til API-endene. Postman er et frittstående verktøy som utøver web-APIer ved å komme med HTTP-forespørsler utenfor tjenesten.

Når du bruker Postman, trenger vi ikke skrive noen HTTP-klientinfrastrukturkode bare for å teste. I stedet lager vi testserier kalt samlinger og lar Postman samhandle med API-en vår.

I denne opplæringen vil vi se hvordan du lager en Postman Collection som kan teste et REST API.

2. Oppsett

Før vi begynner med samlingen, må vi sette opp miljøet.

2.1. Installerer postbud

Postman er tilgjengelig for Linux, Mac og Windows. Verktøyet kan lastes ned og installeres fra Postmann-nettstedet.

Etter å ha avvist skjermbildet, kan vi se brukergrensesnittet:

2.2. Kjører serveren

Postbud trenger en live HTTP-server for å behandle forespørslene. For denne opplæringen bruker vi et tidligere Baeldung-prosjekt, vår-støvel-hvile, som er tilgjengelig på GitHub.

Som vi kanskje gjetter fra tittelen, vår-støvel-hvile er en Spring Boot-applikasjon. Vi bygger appen med Maven-målet installere. Når vi er bygget, lanserer vi serveren med det tilpassede Maven-målet spring-boot: løp.

For å bekrefte at serveren kjører, kan vi trykke denne URL-en i nettleseren vår:

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

Denne tjenesten bruker en minnedatabase. Alle poster slettes når serveren stoppes.

3. Opprette en postbudssamling

En samling i Postman er en serie HTTP-forespørsler. Postbud lagrer alle aspekter av forespørslene, inkludert overskrifter og meldingsorganer. Derfor, vi kan kjøre forespørslene i rekkefølge som halvautomatiske tester.

La oss begynne med å lage en ny samling. Vi kan klikke på rullegardinpilen på Ny og velg Samling:

Når LAG EN NY SAMLING dialogboksen vises, kan vi gi navnet på samlingen vår “foo API-test“. Til slutt klikker vi på Skape -knappen for å se den nye samlingen vår vises i listen til venstre:

Når samlingen vår er opprettet, kan vi holde markøren over den for å avsløre to menyknapper. Piltasten åpner et trekkpanel til høyre som gir tilgang til Collection Runner. Omvendt åpner ellipseknappen en rullegardinmeny som inneholder en rekke operasjoner på samlingen.

4. Legge til en POST-forespørsel

4.1. Opprette en ny forespørsel

Nå som vi har en tom samling, la oss legge til en forespørsel som treffer API-en vår. Spesielt, la oss sende en POST-melding til URI / auth / foos. Å gjøre det, vi åpner ellipsemenyen i samlingen vår og velger Legg til forespørsel.

Når SPAR FORESPØRSEL dialogboksen vises, la oss gi et beskrivende navn, for eksempel “Legg til en foo ”. Klikk deretter på knappen Lagre til foo API-test.

Når forespørselen er opprettet, kan vi se at samlingen vår indikerer en forespørsel. Men hvis samlingen vår ikke er utvidet, kan vi ikke se forespørselen ennå. I så fall kan vi klikke på samlingen for å utvide den.

Nå skal vi se den nye forespørselen som er oppført under samlingen vår. Vi kan se at den nye forespørselen som standard er en HTTP GET, som ikke er det vi ønsker. Vi fikser det i neste avsnitt:

4.2. Redigere forespørselen

For å redigere forespørselen, la oss klikke på den og laste den inn i forespørselsredigeringsfanen:

Selv om forespørselsredigereren har mange alternativer, trenger vi bare noen få av dem foreløpig.

For det første, la oss bruke rullegardinmenyen for å endre metoden fra GET til POST.

For det andre trenger vi en URL. Til høyre for rullegardinmenyen er en tekstboks for forespørselens URL. Så la oss angi det nå:

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

Det siste trinnet er å gi et budskap. Under URL-adressen er det en rad med faneoverskrifter. Vi klikker på Kropp faneoverskrift for å komme til kroppsredigereren.

I Kropp kategorien, rett over tekstområdet, er det en rad med radioknapper og en rullegardin. Disse styrer formateringen og innholdstypen til forespørselen.

Tjenesten vår godtar JSON-data, så vi velger rå radioknapp. I rullegardinmenyen til høyre bruker vi JSON (applikasjon / json) innholdstype.

Når kodingen og innholdstypen er satt, legger vi til vårt JSON-innhold i tekstområdet:

{"name": "Transformers"}

Til slutt, la oss være sikker på å lagre endringene ved å trykke Ctrl-S eller treffer Lagre knapp. De Lagre -knappen er plassert til høyre for Sende knapp. Når vi har lagret, kan vi se at forespørselen er oppdatert til POST i listen til venstre:

5. Kjøre forespørselen

5.1. Kjører en enkelt forespørsel

For å kjøre en enkelt forespørsel, klikker vi bare på Sende knapp til høyre for URL-adressen. Når vi klikker Sende, svarpanelet åpnes under forespørselspanelet. Det kan være nødvendig å bla nedover for å se det:

La oss undersøke resultatene våre. Spesielt i topptekstlinjen ser vi at forespørselen vår lyktes med statusen 201 Opprettet. Videre viser responsorganet at vår Transformatorer posten mottok en ID på 1.

5.2. Bruke Collection Runner

I motsetning til Sende knappen, kan samlingsløperen utføre en hel samling. For å starte samlingsløperen holder vi markøren over vår foo API-test samling og klikk på pilen til høyre. I trekk-høyre-panelet kan vi se a Løpe knappen, så la oss klikke på den:

Når vi klikker på Løpe -knappen samlingsløperen åpnes i et nytt vindu. Fordi vi lanserte den fra samlingen vår, er løperen allerede initialisert til samlingen vår:

Samlingsløperen tilbyr alternativer som påvirker testkjøringen, men vi trenger dem ikke for denne øvelsen. La oss gå direkte til Kjør foo API-test knappen nederst og klikk på den.

Når vi kjører samlingen, endres visningen til Kjør resultater. I dette synet, vi ser en liste over tester som er merket grønt for suksess og rødt for feil.

Selv om forespørselen vår ble sendt, indikerer løperen at null tester bestått og null tester mislyktes. Dette er fordi vi ikke har lagt til tester i forespørselen vår ennå:

6. Testing av responsen

6.1. Legge til tester i en forespørsel

For å lage en test, la oss gå tilbake til forespørselsredigeringspanelet der vi bygde POST-metoden vår. Vi klikker på Tester kategorien som ligger under URL-en. Når vi gjør det, vises testpanelet:

I Tests-panelet skriver vi JavaScript som vil bli utført når svaret mottas fra serveren.

Postman tilbyr innebygde variabler som gir tilgang til forespørselen og svaret. Videre kan en rekke JavaScript-biblioteker importeres ved hjelp av krever () syntaks.

Det er altfor mange skriptfunksjoner til å dekke i denne opplæringen. Imidlertid er den offisielle Postman-dokumentasjonen en utmerket ressurs om dette emnet.

La oss fortsette med å legge til tre tester i forespørselen vår:

pm.test ("suksessstatus", () => pm.response.to.be.success); pm.test ("name is correct", () => pm.expect (pm.response.json (). name) .to.equal ("Transformers")); pm.test ("id ble tildelt", () => pm.expect (pm.response.json (). id) .to.be.not.null);

Som vi kan se, disse testene bruker det globale kl modul levert av Postman. Spesielt bruker testene pm.test (), pm.expect (), og pm.svar.

De pm.test () funksjon godtar en etikett og en påstandsfunksjon, som for eksempel forvent (). Vi bruker pm.expect () for å hevde betingelser for innholdet i svaret JSON.

De pm.svar objektet gir tilgang til forskjellige egenskaper og operasjoner på svaret som returneres fra serveren. Tilgjengelige egenskaper inkluderer blant annet responsstatus og JSON-innhold.

Som alltid lagrer vi endringene med Ctrl-S eller Lagre knapp.

6.2. Kjører testene

Nå som vi har testene våre, la oss kjøre forespørselen igjen. Trykk på Sende -knappen viser resultatene i Testresultater fanen i svarpanelet:

På samme måte viser samlingsløperen nå testresultatene våre. Nærmere bestemt viser sammendraget øverst til venstre det oppdaterte bestått og mislyktes totaler. Under sammendraget er en liste som viser hver test med status:

6.3. Ser på postbudkonsollen

De Postbudkonsoll er et nyttig verktøy for å lage og feilsøke skript. Vi finner konsollen under Utsikt meny med varenavnet Vis postbudskonsollen. Når konsollen åpnes, åpnes den i et nytt vindu.

Mens konsollen er åpen, registrerer den alle HTTP-forespørsler og svar. Videre når manus bruker console.log (), de Postbudkonsoll viser disse meldingene:

7. Opprette en sekvens av forespørsler

Så langt har vi fokusert på en enkelt HTTP-forespørsel. La oss nå se hva vi kan gjøre med flere forespørsler. Ved å koble sammen en rekke forespørsler, kan vi simulere og teste en klient-server-arbeidsflyt.

I denne delen, la oss bruke det vi har lært for å lage en sekvens av forespørsler. Spesielt vil vi legge til tre flere forespørsler om å utføre etter POST-forespørselen vi allerede har opprettet. Disse blir en GET, en SLETT, og til slutt, en annen GET.

7.1. Fange responsverdier i variabler

Før vi oppretter våre nye forespørsler, la oss gjøre en endring i vår eksisterende POST-forespørsel. Fordi vi ikke vet hvilken id serveren vil tildele hver foo For eksempel kan vi bruke en variabel til å fange ID-en som returneres av serveren.

For å fange den IDen, legger vi til en linje til slutten av POST-forespørselens testskript:

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

De pm.variables.set () funksjon tar en verdi og tilordner den til en midlertidig variabel. I dette tilfellet lager vi en id variabel for å lagre objektets id-verdi. Når den er angitt, kan vi få tilgang til denne variabelen i senere forespørsler.

7.2. Legge til en GET-forespørsel

Nå, ved hjelp av teknikkene fra forrige seksjoner, la oss legge til en GET-forespørsel etter POST-forespørselen.

Med denne GET-forespørselen vil vi hente det samme foo for eksempel at POST-forespørselen ble opprettet. La oss kalle denne GET-forespørselen som “få en foo“.

URL-en til GET-forespørselen er:

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

I denne URL-en refererer vi til id variabel som vi tidligere angav under POST-forespørselen. Dermed bør GET-forespørselen hente den samme forekomsten som ble opprettet av POST.

Når det vises variabler utenfor skriptene, henvises det til ved hjelp av syntaksen med dobbelt avstivning {{id}}.

Siden det ikke er noe organ for en GET-forespørsel, la oss fortsette direkte til Tester fanen. Fordi testene er like, kan vi kopiere testene fra POST-forespørselen, og deretter gjøre noen endringer.

For det første, vi trenger ikke å stille inn id variabel igjen, så la oss ikke kopiere den linjen.

For det andre vet vi hvilken id vi kan forvente denne gangen, så la oss bekrefte den. Vi kan bruke id variabel for å gjøre det:

pm.test ("suksessstatus", () => pm.response.to.be.success); pm.test ("name is correct", () => pm.expect (pm.response.json (). name) .to.equal ("Transformers")); pm.test ("id er riktig", () => pm.expect (pm.response.json (). id) .to.equal (pm.variables.get ("id")));

Siden dobbelstagssyntaks ikke er gyldig JavaScript, bruker vi pm.variables.get () funksjon for å få tilgang til id variabel.

Til slutt, la oss lagre endringene som vi har gjort før.

7.3. Legger til en SLETT-forespørsel

Deretter legger vi til en DELETE-forespørsel som fjerner foo objekt fra serveren.

Vi fortsetter med å legge til en ny forespørsel etter GET, og sette metoden til SLETT. Vi kan gi denne forespørselen navn “slett en foo“.

URLen til slettingen er identisk med GET URL:

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

Svaret vil ikke ha et organ å teste, men vi kan teste responskoden. Derfor vil DELETE-forespørselen bare ha en test:

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

7.4. Bekreft SLETTING

Til slutt, la oss legge til en ny kopi av GET-forespørselen for å bekrefte at DELETE virkelig fungerte. Denne gangen, la oss duplisere vår første GET-forespørsel i stedet for å lage en forespørsel fra bunnen av.

For å duplisere en forespørsel høyreklikker vi på forespørselen for å vise rullegardinmenyen. Deretter velger vi Duplisere.

Den dupliserte forespørselen vil ha ordet Kopiere vedlagt navnet. La oss gi den nytt navn til “bekreft sletting”For å unngå forvirring. De Gi nytt navn alternativet er tilgjengelig ved å høyreklikke på forespørselen.

Som standard vises den dupliserte forespørselen umiddelbart etter den opprinnelige forespørselen. Som et resultat må vi dra den under DELETE-forespørselen.

Det siste trinnet er å endre testene. Før vi gjør det, la oss imidlertid benytte anledningen til å se en mislykket test.

Vi har kopiert GET-forespørselen og flyttet den etter SLETTET, men vi har ikke oppdatert testene ennå. Siden DELETE-forespørselen burde ha slettet objektet, bør testene mislykkes.

La oss sørge for å lagre alle forespørslene våre, og deretter trykke Prøv på nytt i samlingsløperen. Som forventet har testene våre mislyktes:

Nå som vår korte avstikker er fullført, la oss fikse testene.

Ved å gjennomgå de mislykkede testene, kan vi se at serveren svarer med 500-status. Derfor endrer vi statusen i testen.

Videre ved å se på det mislykkede svaret i Postbudkonsoll, lærer vi at svaret inkluderer en årsaken eiendom. Videre, den årsaken egenskapen inneholder strengen “Ingen verdi til stede“. Vi kan også teste for det:

pm.test ("status er 500", () => pm.response.to.have.status (500)); pm.test ("no value present", () => pm.expect (pm.response.json (). årsak) .to.equal ("No value present"));

7.5. Kjører hele samlingen

Nå som vi har lagt til alle forespørslene, la oss kjøre hele samlingen i samlingsløperen:

Hvis alt har gått etter planen, bør vi ha ni vellykkede tester.

8. Eksportere og importere samlingen

Mens Postmann lagrer samlingene våre på et privat, lokalt sted, kan det være lurt å dele samlingen. For å gjøre det eksporterer vi samlingen til en JSON-fil.

De Eksport kommandoen er tilgjengelig i ellipsemenyen i samlingen. Når du blir bedt om en JSON-filversjon, la oss velge den siste anbefalte versjonen.

Etter at vi har valgt filversjonen, vil Postman be om et filnavn og sted for den eksporterte samlingen. Vi kan for eksempel velge en mappe i GitHub-prosjektet vårt.

For å importere en tidligere eksportert samling, bruker vi Import knapp. Vi finner den på verktøylinjen i hovedboksvinduet. Når Postman ber om en filplassering, kan vi navigere til JSON-filen vi ønsker å importere.

Det er verdt å merke seg at Postman ikke sporer eksporterte filer. Som et resultat viser ikke Postman eksterne endringer før vi importerer samlingen på nytt.

9. Konklusjon

I denne artikkelen har vi brukt Postman til å lage semi-automatiserte tester for et REST API. Mens denne artikkelen fungerer som en introduksjon til Postmans grunnleggende funksjoner, har vi knapt skrapet overflaten av dens evner. Postboks online dokumentasjon er en verdifull ressurs for dypere leting.

Samlingen opprettet i denne veiledningen er tilgjengelig på GitHub.