streamalism.org

1. Oversigt

I denne artikel introducerer vi Karate, en Behavior Driven Development (BDD) testramme for Java.

2. Karate og BDD

Karate erbygget oven på agurk, en anden BDD-testramme og deler nogle af de samme koncepter. En af disse er brugen af ​​en agurkafil, der beskriver den testede funktion. Men i modsætning til agurk er test ikke skrevet i Java og er fuldt beskrevet i Gherkin-filen.

En agurkafil gemmes med “.funktion ” udvidelse. Det begynder med Funktion nøgleord efterfulgt af funktionsnavnet på samme linje. Den indeholder også forskellige testscenarier, der hver begynder med nøgleordet Scenarie og består af flere trin med nøgleordene Givet, Hvornår, Derefter, Ogog Men.

Mere om agurk og struktur af agurk kan findes her.

3. Maven-afhængigheder

For at gøre brug af Karate i et Maven-projekt skal vi tilføje karate-apache afhængighed af pom.xml:

 com.intuit.karate karate-apache 0.6.0 

Vi har også brug for karate-junit4 afhængighed for at lette JUnit-test:

 com.intuit.karate karate-junit4 0.6.0 

4. Oprettelse af tests

Vi starter med at skrive tests til nogle almindelige scenarier i en agurk Funktion fil.

4.1. Test af statuskoden

Lad os skrive et scenario, der tester et GET-slutpunkt og kontrollerer, om det returnerer et 200 (OK) HTTP-statuskode:

Scenarie: Test af gyldigt GET-slutpunkt givet url '// localhost: 8097 / bruger / get' Når metode GET Så status 200

Dette fungerer selvfølgelig med alle mulige HTTP-statuskoder.

4.2. Test af svaret

Lad os skrive et andet scenarie, der tester, at REST-slutpunktet returnerer et specifikt svar:

Scenarie: Test af det nøjagtige svar fra et GET-slutpunkt Givet url '// localhost: 8097 / bruger / get' Når metode GET Så status 200 Og match $ == {id: "1234", navn: "John Smith"}

Det match operation bruges til validering hvor '$' repræsenterer svaret. Ovenstående scenarie kontrollerer, at svaret nøjagtigt matcher '{id: ”1234 ″, navn:” John Smith ”} '.

Vi kan også specifikt kontrollere værdien af id Mark:

Og match $ .id == "1234"

Det match operation kan også bruges til at kontrollere, om svaret indeholder visse felter. Dette er nyttigt, når kun visse felter skal kontrolleres, eller når ikke alle svarfelter er kendt:

Scenarie: Test af, at GET-svar indeholder specifikt felt Givet url '// localhost: 8097 / bruger / get' Når metode GET Så indeholder status 200 Og match $ {id: "1234"}

4.3. Validering af svarværdier med markører

I det tilfælde hvor vi ikke kender den nøjagtige værdi, der returneres, kan vi stadig validere værdien ved hjælp af markører - pladsholdere til matchende felter i svaret.

For eksempel kan vi bruge en markør til at indikere, om vi forventer en nul værdi eller ej:

• #nul
• #notnull

Eller vi kan bruge en markør til at matche en bestemt type værdi i et felt:

• #boolean
• #nummer
• #snor

Andre markører er tilgængelige, når vi forventer, at et felt indeholder et JSON-objekt eller array:

• #array
• #objekt

Og der er markører til matchning på et bestemt format eller et regulært udtryk, og en der evaluerer et boolsk udtryk:

• #uuid - værdi overholder UUID-formatet
• #regex STR - værdi matcher det regulære udtryk STR
• #? EXPR - hævder, at JavaScript-udtrykket EXPR evaluerer til rigtigt

Endelig, hvis vi ikke ønsker nogen form for kontrol på et felt, kan vi bruge #ignorere markør.

Lad os omskrive ovenstående scenarie for at kontrollere, at id felt ikke er nul:

Scenarie: Test GET anmod nøjagtigt svar givet url '// localhost: 8097 / bruger / get' Når metode GET Så status 200 Og match $ == {id: "# notnull", navn: "John Smith"}

4.4. Test af et POST-slutpunkt med et anmodningsorgan

Lad os se på et slutscenarie, der tester et POST-slutpunkt og tager en anmodningsinstans:

Scenarie: Afprøvning af et POST-slutpunkt med anmodningens organ Angivet url '// localhost: 8097 / bruger / opret' Og anmod {id: '1234', navn: 'John Smith'} Når metode POST Så indeholder status 200 Og match $ {id : "# notnull"}

5. Løbstest

Nu hvor testscenarierne er færdige, kan vi køre vores tests ved at integrere Karate med JUnit.

Vi bruger @CucumberOptions kommentar for at specificere den nøjagtige placering af Funktion filer:

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

For at demonstrere REST API bruger vi en WireMock-server.

I dette eksempel spotter vi alle de slutpunkter, der testes i den metode, der er kommenteret med @BeforeClass. Vi lukker WireMock-serveren i den metode, der er kommenteret med @Efter skole:

privat statisk WireMockServer wireMockServer = ny WireMockServer (WireMockConfiguration.options (). port (8097)); @BeforeClass offentlig statisk ugyldig setUp () kaster undtagelse {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 (indeholder ("id")) .willReturn (aResponse () .withStatus (200) .withHeader ("Content-Type", "application / json") .withBody ("{\" id \ ": \" 1234 \ ", navn: \" John Smith \ "}"))); } @AfterClass offentlig statisk ugyldighed tearDown () kaster undtagelse {wireMockServer.stop (); }

Når vi kører KarateUnitTest klasse oprettes REST-slutpunkterne af WireMock Server, og alle scenarierne i den angivne funktionsfil køres.

6. Konklusion

I denne vejledning så vi på, hvordan man testede REST API'er ved hjælp af Karate Testing Framework.

Komplet kildekode og alle kodestykker til denne artikel kan findes på GitHub.