REST API-testen met karate

1. Overzicht

In dit artikel introduceren we Karate, een Behavior Driven Development (BDD) testraamwerk voor Java.

2. Karate en BDD

Karate isgebouwd bovenop komkommer, een ander BDD-testraamwerk, en deelt enkele van dezelfde concepten. Een daarvan is het gebruik van een augurkbestand, dat de geteste functie beschrijft. In tegenstelling tot Cucumber worden tests echter niet in Java geschreven en worden ze volledig beschreven in het Gherkin-bestand.

Een augurkbestand wordt opgeslagen met de ".voorzien zijn van" uitbreiding. Het begint met de Voorzien zijn van trefwoord, gevolgd door de naam van het element op dezelfde regel. Het bevat ook verschillende testscenario's, die elk beginnen met het trefwoord Scenario en bestaande uit meerdere stappen met de trefwoorden Gegeven, Wanneer, Dan, En, en Maar.

Meer over komkommer en de augurkstructuur vind je hier.

3. Maven afhankelijkheden

Om Karate in een Maven-project te kunnen gebruiken, moeten we de karate-apache afhankelijkheid van de pom.xml:

 com.intuit.karate karate-apache 0.6.0 

We hebben ook de karate-junit4 afhankelijkheid om JUnit-testen te vergemakkelijken:

 com.intuit.karate karate-junit4 0.6.0 

4. Tests maken

We beginnen met het schrijven van tests voor enkele veelvoorkomende scenario's in een augurk Voorzien zijn van het dossier.

4.1. De statuscode testen

Laten we een scenario schrijven dat een GET-eindpunt test en controleert of het een 200 (OK) HTTP-statuscode:

Scenario: testen geldig GET-eindpunt Gegeven url '// localhost: 8097 / user / get' Wanneer methode GET Dan status 200

Dit werkt uiteraard met alle mogelijke HTTP-statuscodes.

4.2. De reactie testen

Laten we een ander scenario schrijven dat test of het REST-eindpunt een specifiek antwoord retourneert:

Scenario: het exacte antwoord testen van een GET-eindpunt Gegeven url '// localhost: 8097 / user / get' Wanneer methode GET Dan status 200 En match $ == {id: "1234", naam: "John Smith"}

De bij elkaar passen operatie wordt gebruikt voor de validatie waar ‘$' vertegenwoordigt het antwoord. Dus in het bovenstaande scenario wordt gecontroleerd of het antwoord exact overeenkomt met ‘{id: ”1234 ″, naam:” John Smith ”} '.

We kunnen ook specifiek controleren op de waarde van de ID kaart veld:

En match $ .id == "1234"

De bij elkaar passen operatie kan ook worden gebruikt om te controleren of het antwoord bepaalde velden bevat. Dit is handig als alleen bepaalde velden moeten worden aangevinkt of als niet alle responsvelden bekend zijn:

Scenario: testen of GET-antwoord een specifiek veld bevat Gegeven url '// localhost: 8097 / user / get' Wanneer methode GET Dan status 200 En match $ bevat {id: "1234"}

4.3. Antwoordwaarden valideren met markeringen

In het geval dat we de exacte waarde die wordt geretourneerd niet weten, kunnen we de waarde nog steeds valideren met markeringen - tijdelijke aanduidingen voor overeenkomende velden in het antwoord.

We kunnen bijvoorbeeld een marker gebruiken om aan te geven of we een verwachten nul waarde of niet:

  • #nul
  • #niet nul

Of we kunnen een markering gebruiken om een ​​bepaald type waarde in een veld te matchen:

  • #boolean
  • #aantal
  • #draad

Er zijn andere markeringen beschikbaar voor wanneer we verwachten dat een veld een JSON-object of array bevat:

  • #matrix
  • #voorwerp

En er zijn markeringen voor het matchen op een bepaald formaat of reguliere expressie en een die een booleaanse expressie evalueert:

  • #uuid - waarde komt overeen met het UUID-formaat
  • #regex STR - waarde komt overeen met de reguliere expressie STR
  • #? EXPR - beweert dat de JavaScript-expressie EXPR evalueert naar waar

Ten slotte, als we geen enkele vorm van controle op een veld willen, kunnen we de #negeren markeerstift.

Laten we het bovenstaande scenario herschrijven om te controleren of het ID kaart veld is dat niet nul:

Scenario: Test GET verzoek exact antwoord Gegeven url '// localhost: 8097 / user / get' Wanneer methode GET Dan status 200 En match $ == {id: "# notnull", naam: "John Smith"}

4.4. Een POST-eindpunt testen met een aanvraagtekst

Laten we eens kijken naar een laatste scenario dat een POST-eindpunt test en een aanvraagtekst gebruikt:

Scenario: testen van een POST-eindpunt met request body Gegeven url '// localhost: 8097 / user / create' En verzoek {id: '1234', naam: 'John Smith'} Wanneer methode POST Dan status 200 En match $ bevat {id :"#niet nul"}

5. Tests uitvoeren

Nu de testscenario's zijn voltooid, kunnen we onze tests uitvoeren door Karate te integreren met JUnit.

We gebruiken de @CucumberOptions annotatie om de exacte locatie van het Voorzien zijn van bestanden:

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

Om de REST API te demonstreren, gebruiken we een WireMock-server.

Voor dit voorbeeld bespotten we alle eindpunten die worden getest in de methode die is geannoteerd met @Voor klas. We zullen de WireMock-server afsluiten volgens de methode die is geannoteerd met @Na de les:

privé statische WireMockServer wireMockServer = nieuwe WireMockServer (WireMockConfiguration.options (). poort (8097)); @BeforeClass public static void setUp () gooit Uitzondering {wireMockServer.start (); configureFor ("localhost", 8097); stubFor (get (urlEqualTo ("/ user / get")) .willReturn (aResponse () .withStatus (200) .withHeader ("Content-Type", "application / json") .withBody ("{\" id \ " : \ "1234 \", naam: \ "John Smith \"} "))); stubFor (post (urlEqualTo ("/ user / create")) .withHeader ("content-type", equalTo ("application / json")) .withRequestBody (met ("id")) .willReturn (aResponse () .withStatus (200) .withHeader ("Content-Type", "application / json") .withBody ("{\" id \ ": \" 1234 \ ", naam: \" John Smith \ "}"))); } @AfterClass openbare statische leegte tearDown () gooit uitzondering {wireMockServer.stop (); }

Wanneer we het KarateUnitTest class, worden de REST Endpoints gemaakt door de WireMock Server en worden alle scenario's in het opgegeven feature-bestand uitgevoerd.

6. Conclusie

In deze tutorial hebben we gekeken naar het testen van REST API's met behulp van het Karate Testing Framework.

De volledige broncode en alle codefragmenten voor dit artikel zijn te vinden op GitHub.


$config[zx-auto] not found$config[zx-overlay] not found