streamalism.org

1. Oversikt

I denne artikkelen introduserer vi Karate, et rammeverk for atferdsdrevet utvikling (BDD) for Java.

2. Karate og BDD

Karate er detbygget på toppen av agurk, et annet BDD-testrammeverk, og deler noen av de samme konseptene. En av disse er bruk av en Gherkin-fil, som beskriver den testede funksjonen. Imidlertid, i motsetning til agurk, er ikke tester skrevet i Java, og de er fullstendig beskrevet i Gherkin-filen.

En agurkafil lagres med “.trekk" Utvidelse. Det begynner med Trekk nøkkelord, etterfulgt av funksjonsnavnet på samme linje. Den inneholder også forskjellige testscenarier, hver begynnelse med nøkkelordet Scenario og består av flere trinn med nøkkelordene Gitt, Når, Deretter, Og, og Men.

Mer om agurk og agurkestrukturen finner du her.

3. Maven-avhengigheter

For å gjøre bruk av Karate i et Maven-prosjekt, må vi legge til karate-apache avhengighet av pom.xml:

 com.intuit.karate karate-apache 0.6.0 

Vi trenger også karate-junit4 avhengighet for å lette JUnit-testing:

 com.intuit.karate karate-junit4 0.6.0 

4. Lage tester

Vi begynner med å skrive tester for noen vanlige scenarier i en agurk Trekk fil.

4.1. Testing av statuskoden

La oss skrive et scenario som tester et GET-endepunkt og sjekker om det returnerer et 200 (OK) HTTP-statuskode:

Scenario: Test av gyldig GET-endepunkt Gitt url '// localhost: 8097 / user / get' Når metode GET Then status 200

Dette fungerer åpenbart med alle mulige HTTP-statuskoder.

4.2. Testing av svaret

La oss skrive et annet scenario som tester at REST-endepunktet returnerer et spesifikt svar:

Scenario: Testing av den eksakte responsen til et GET-endepunkt Gitt url '// localhost: 8097 / user / get' When method GET Then status 200 And match $ == {id: "1234", name: "John Smith"}

De kamp operasjonen brukes til validering hvor '$' representerer responsen. Så scenariet ovenfor kontrollerer at svaret stemmer overens med{id: ”1234 ″, navn:” John Smith ”} '.

Vi kan også sjekke spesifikt for verdien av id felt:

Og match $ .id == "1234"

De kamp operasjonen kan også brukes til å sjekke om svaret inneholder visse felt. Dette er nyttig når bare visse felt må kontrolleres eller når ikke alle svarfeltene er kjent:

Scenario: Testing av at GET-respons inneholder spesifikt felt Gitt url '// localhost: 8097 / user / get' When method GET Then status 200 And match $ inneholder {id: "1234"}

4.3. Validere responsverdier med markører

I tilfelle hvor vi ikke vet den eksakte verdien som returneres, kan vi fortsatt validere verdien ved hjelp av markører - plassholdere for samsvarende felt i svaret.

For eksempel kan vi bruke en markør for å indikere om vi forventer en null verdi eller ikke:

• #null
• #ikke null

Eller vi kan bruke en markør for å matche en bestemt type verdi i et felt:

• #boolean
• #Nummer
• #streng

Andre markører er tilgjengelige for når vi forventer at et felt skal inneholde et JSON-objekt eller en matrise:

• #array
• #gjenstand

Og det er markører for samsvar på et bestemt format eller vanlig uttrykk, og en som evaluerer et boolsk uttrykk:

• #uuid - verdien samsvarer med UUID-formatet
• #regex STR - verdien samsvarer med det vanlige uttrykket STR
• #? EXPR - hevder at JavaScript-uttrykket EXPR evaluerer til ekte

Til slutt, hvis vi ikke vil ha noen form for kontroll på et felt, kan vi bruke #overse markør.

La oss omskrive scenarioet ovenfor for å kontrollere at id feltet ikke er null:

Scenario: Test GET forespørsel om nøyaktig respons Gitt url '// localhost: 8097 / user / get' Når metode GET Så status 200 Og match $ == {id: "# notnull", navn: "John Smith"}

4.4. Testing av et POST-endepunkt med et forespørselsorgan

La oss se på et endelig scenario som tester et POST-endepunkt og tar en forespørselsinstans:

Scenario: Testing av et POST-sluttpunkt med forespørselslegemet Gitt url '// localhost: 8097 / bruker / opprett' Og forespørsel {id: '1234', navn: 'John Smith'} Når metode POST Da inneholder status 200 og match $ {id :"#ikke null"}

5. Kjører tester

Nå som testscenariene er fullført, kan vi kjøre testene våre ved å integrere Karate med JUnit.

Vi bruker @CucumberOptions kommentar for å spesifisere den nøyaktige plasseringen av Trekk filer:

@RunWith (Karate.class) @CucumberOptions (features = "classpath: karate") offentlig klasse KarateUnitTest {// ...}

For å demonstrere REST API bruker vi en WireMock-server.

For dette eksemplet spotter vi alle endepunktene som testes i metoden som er merket med @BeforeClass. Vi stenger WireMock-serveren i metoden som er merket med @Etter timen:

privat statisk WireMockServer wireMockServer = ny WireMockServer (WireMockConfiguration.options (). port (8097)); @BeforeClass offentlig statisk ugyldig setUp () kaster unntak {wireMockServer.start (); configureFor ("localhost", 8097); stubFor (get (urlEqualTo ("/ user / get")) .willReturn (aResponse () .withStatus (200) .withHeader ("Content-Type", "application / json") .withBody ("{\" id \ " : \ "1234 \", navn: \ "John Smith \"} "))); stubFor (post (urlEqualTo ("/ user / create")) .withHeader ("content-type", equalTo ("application / json")) .withRequestBody (inneholder ("id")) .willReturn (aResponse () .withStatus (200) .withHeader ("Content-Type", "application / json") .withBody ("{\" id \ ": \" 1234 \ ", navn: \" John Smith \ "}"))); } @AfterClass offentlig statisk ugyldighet tearDown () kaster unntak {wireMockServer.stop (); }

Når vi kjører KarateUnitTest klasse, blir REST-endepunktene opprettet av WireMock Server, og alle scenariene i den angitte funksjonsfilen kjøres.

6. Konklusjon

I denne opplæringen så vi på hvordan vi kan teste REST APIer ved hjelp av Karate Testing Framework.

Komplett kildekode og alle kodebiter for denne artikkelen finner du på GitHub.