REST API tesztelés a Karate-szal

1. Áttekintés

Ebben a cikkben bemutatjuk a Karate nevű viselkedésvezérelt fejlesztési (BDD) tesztelési keretrendszert a Java számára.

2. Karate és BDD

A karate azuborka tetejére épült, egy másik BDD tesztelési keretrendszer, és ugyanazokat a koncepciókat osztja meg. Ezek egyike Gherkin fájl használata, amely leírja a tesztelt funkciót. Azonban az uborkával ellentétben a teszteket nem Java nyelven írják, és a Gherkin fájlban írják le teljes mértékben.

Egy Gherkin fájlt a „.funkció" kiterjesztés. Azzal kezdődik Funkció kulcsszó, majd a tulajdonság neve ugyanazon a soron. Különféle tesztforgatókönyveket is tartalmaz, amelyek mindegyike a kulcsszóval kezdődik Forgatókönyv és több lépésből áll a kulcsszavakkal Adott, Mikor, Azután, És, és De.

További információ az uborkáról és a uborka szerkezetről itt található.

3. Maven-függőségek

Ahhoz, hogy a Karate-ot felhasználhassuk egy Maven projektben, hozzá kell adnunk a karate-apache függőség a pom.xml:

 com.intuit.karate karate-apache 0.6.0 

Szükségünk lesz a karate-junit4 függőség a JUnit tesztelésének megkönnyítéséhez:

 com.intuit.karate karate-junit4 0.6.0 

4. Tesztek készítése

Kezdjük azzal, hogy teszteket írunk néhány általános forgatókönyvre egy Gherkin-ben Funkció fájl.

4.1. Az állapotkód tesztelése

Írjunk egy forgatókönyvet, amely tesztel egy GET-végpontot, és ellenőrzi, hogy a-t ad-e vissza 200 (OK) HTTP állapotkód:

Forgatókönyv: Érvényes GET végpont tesztelése Adott url '// localhost: 8097 / user / get' Amikor a módszer GET Akkor 200 állapot

Ez nyilvánvalóan működik az összes lehetséges HTTP állapotkóddal.

4.2. A válasz tesztelése

Írjunk egy másik forgatókönyvet, amely teszteli, hogy a REST végpont egy adott választ ad vissza:

Forgatókönyv: GET-végpont pontos válaszának tesztelése Adott url '// localhost: 8097 / user / get' When method GET Then status 200 And match $ == {id: "1234", name: "John Smith"}

A mérkőzés műveletet használják az érvényesítéshez hol '$' képviseli a választ. Tehát a fenti forgatókönyv ellenőrzi, hogy a válasz pontosan megfelel-e a{id: ”1234 ″, név:“ John Smith ”}”.

Kifejezetten ellenőrizhetjük a id terület:

És illessze meg a $ .id == "1234" -t

A mérkőzés művelet segítségével ellenőrizhető, hogy a válasz tartalmaz-e bizonyos mezőket. Ez akkor hasznos, ha csak bizonyos mezőket kell ellenőrizni, vagy ha nem minden válaszmező ismeretes:

Forgatókönyv: Annak tesztelése, hogy a GET válasz tartalmaz-e egy adott mezőt Adott url '// localhost: 8097 / user / get' Amikor a módszer GET Akkor 200 állapot és a $ match tartalmaz {id: "1234"}

4.3. Válaszértékek érvényesítése markerekkel

Abban az esetben, ha nem ismerjük a pontos értéket, akkor is érvényesíthetjük az értéket a használatával markerek - helyőrzők a válasz mezőinek egyezéséhez.

Például jelölővel használhatjuk annak jelzését, hogy várunk-e a-t nulla érték vagy sem:

  • #nulla
  • #nem nulla

Vagy használhatunk jelölőt egy adott típusú érték egyezéséhez egy mezőben:

  • # logikai
  • #szám
  • #húr

További jelölők állnak rendelkezésre arra az esetre, ha egy mezőtől azt várjuk, hogy tartalmaz egy JSON objektumot vagy tömböt:

  • #sor
  • #tárgy

És vannak jelölők egy bizonyos formátum vagy reguláris kifejezés illesztésére, és olyanok, amelyek kiértékelik a logikai kifejezést:

  • #uuid - érték megfelel az UUID formátumnak
  • #regex STR - érték megegyezik a reguláris kifejezéssel STR
  • #? EXPR - azt állítja, hogy a JavaScript kifejezés EXPR értékeli, hogy igaz

Végül, ha nem akarunk semmiféle ellenőrzést egy mezőn, használhatjuk a #figyelmen kívül hagyni jelző.

Írjuk át a fenti forgatókönyvet annak ellenőrzésére, hogy a id mező nem nulla:

Forgatókönyv: Tesztelje a GET kérés pontos válaszát Adott url '// localhost: 8097 / user / get' Amikor a módszer GET Akkor 200 állapotot és egyezik a $ == {id: "# notnull", név: "John Smith"}

4.4. A POST végpont tesztelése egy kérelem törzsével

Nézzünk meg egy olyan végső forgatókönyvet, amely teszteli a POST végpontot és felvesz egy kéréstestet:

Forgatókönyv: POST végpont tesztelése a kérelem törzsével Adott url '// localhost: 8097 / user / create' És kérés {id: '1234', név: 'John Smith'} Amikor a POST módszer akkor a 200 állapot és a $ match tartalmazza a {id :"#nem nulla"}

5. Futó tesztek

Most, hogy a teszt forgatókönyvek elkészültek, a Karate és a JUnit integrálásával futtathatjuk tesztjeinket.

Használjuk a @UborkaOptions annotáció a program pontos helyének meghatározásához Funkció fájlok:

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

A REST API bemutatásához WireMock szervert fogunk használni.

Ebben a példában gúnyolódunk az összes olyan végponttól, amelyet a jegyzetelt módszerrel tesztelnek @Óra előtt. Leállítjuk a WireMock szervert azzal a módszerrel, amellyel jegyzeteltünk @Óra után:

privát statikus WireMockServer wireMockServer = új WireMockServer (WireMockConfiguration.options (). port (8097)); @BeforeClass public static void setUp () dobja a Kivételt {wireMockServer.start (); configureFor ("localhost", 8097); stubFor (get (urlEqualTo ("/ user / get")) .willReturn (aResponse () .withStatus (200) .withHeader ("Content-Type", "application / json") .withBody ("{\" id \ " : \ "1234 \", név: \ "John Smith \"} ")))); stubFor (post (urlEqualTo ("/ user / create")) .withHeader ("content-type", equalTo ("application / json")) .withRequestBody (tartalmazza ("id")) .willReturn (aResponse () .withStatus (200) .withHeader ("Content-Type", "application / json") .withBody ("{\" id \ ": \" 1234 \ ", név: \" John Smith \ "}"))); } @AfterClass public static void tearDown () dobja a Kivételt {wireMockServer.stop (); }

Amikor lefuttatjuk a KarateUnitTest osztályban a REST végpontokat a WireMock Server hozza létre, és a megadott szolgáltatásfájl összes forgatókönyve fut.

6. Következtetés

Ebben az oktatóanyagban megvizsgáltuk, hogyan tesztelhetjük a REST API-kat a Karate Testing Framework segítségével.

A teljes forráskód és a cikk összes kódrészlete megtalálható a GitHubon.


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