A Jersey teszt keretrendszerének felfedezése

1. Áttekintés

Ebben az oktatóanyagban megnézzük a Jersey Test Framework-et, és megtudhatjuk, hogyan használhatjuk az integrációs tesztek gyors megírásához.

Ahogy azt már korábbi cikkekben is láthattuk, Jersey egy nyílt forráskódú keretrendszer a RESTful Web Services fejlesztéséhez. Jersey-ről többet megtudhatunk az API készítésének bemutatásáról a Jersey és Spring című cikkben - itt.

2. Az alkalmazás beállítása

A Jersey Test Framework olyan eszköz, amely segítséget nyújt a kiszolgálóoldali összetevők helyes megvalósításának ellenőrzésében. Mint később látni fogjuk, gyors és felhajtás nélküli módot kínál az integrációs tesztek megírásához és nagyon jól tudja kezelni a HTTP API-kkal való kommunikációt.

Hasonlóképpen, szinte a dobozon kívül működik, és könnyen integrálható a Maven-alapú projektjeinkbe. A keretrendszer elsősorban a JUnit-re épül, bár a TestNG-vel is használható, ami szinte minden környezetben használhatóvá teszi.

A következő szakaszban megnézzük, mely függőségeket kell hozzáadnunk az alkalmazásunkhoz a keretrendszer használatához.

2.1. Maven-függőségek

Először tegyük hozzá a Jersey Test Framework alapvető függőségét a mi magunkhoz pom.xml:

 org.glassfish.jersey.test-framework jersey-test-framework-core 2.27 teszt 

Mint mindig, a legújabb verziót is megkapjuk a Maven Central-tól.

Szinte az összes Jersey-tesztben a defacto Grizzly teszttartály-gyárat használják, amelyet szintén hozzá kell adnunk:

 org.glassfish.jersey.test-framework.providers jersey-test-framework-szolgáltató-grizzly2 2.27 teszt 

Ismét megtalálhatjuk a legújabb verziót a Maven Central-ban.

3. Az első lépések

Ebben a következő szakaszban áttekintjük az egyszerű teszt megírásához szükséges alapvető lépéseket.

Kezdjük az egyszerű tesztelésével Üdvözlet erőforrás a szerverünkön:

@Path ("/ greetings") public class Greetings {@GET @Path ("/ hi") public String getHiGreeting () {return "szia"; }} 

3.1. A teszt konfigurálása

Most határozzuk meg a tesztosztályunkat:

public class GreetingsResourceIntegrationTest kiterjeszti a JerseyTestet {@Override védett alkalmazás configure () {return new ResourceConfig (Greetings.class); } // ...} 

A fenti példában láthatjuk, hogy egy teszt fejlesztéséhez a Jersey Test Framework használatával tesztünknek alosztályra van szüksége JerseyTest.

Ezután felülírjuk a Beállítás metódus, amely egyéni erőforrás-konfigurációt ad vissza a tesztünkhöz, és csak a Üdvözlet forrás. Természetesen ez az az erőforrás, amelyet tesztelni szeretnénk.

3.2. Első tesztünk megírása

Kezdjük azzal, hogy tesztelünk egy egyszerű GET kérést az üdvözlő API-nkon:

@Test public void givenGetHiGreeting_whenCorrectRequest_thenResponseIsOkAndContainsHi () {Response response = target ("/ greetings / hi"). Request () .get (); assertEquals ("A Http válasznak 200-nak kell lennie:", Status.OK.getStatusCode (), response.getStatus ()); assertEquals ("A Http Content-Type legyen:", MediaType.TEXT_HTML, response.getHeaderString (HttpHeaders.CONTENT_TYPE)); Karakterlánc tartalma = response.readEntity (String.osztály); assertEquals ("A ressponse tartalma:", "szia", ​​tartalom); } 

Vegye figyelembe, hogy teljes hozzáféréssel rendelkezünk a HTTP válaszhoz - így tehetünk olyan dolgokat, mint az állapotkód ellenőrzése, hogy megbizonyosodjunk arról, hogy a művelet valóban sikeres volt-e, vagy együtt dolgozhatunk a válasz tényleges törzsével.

Magyarázzuk el részletesebben, mit csinálunk a fenti példában:

  1. Küldjön HTTP GET kérést a következő címre: / / greetings / hi
  2. Ellenőrizze a HTTP állapotkódot és a tartalomtípus válaszfejlécét
  3. Ellenőrizze, hogy a válasz tartalma a „hi” karakterláncot tartalmazza

4. A GET tesztelése az erőforrások lekérése érdekében

Most, hogy láttuk a tesztek létrehozásának alapvető lépéseit. Teszteljük le az egyszerű Fruit API-t, amelyet a kiváló Jersey MVC támogatási cikkben vezettünk be.

4.1. Get Plain JSON

Az alábbi példában a válasz testtel dolgozunk, mint standard JSON karakterlánc:

@Test public void givenFruitExists_whenSearching_thenResponseContainsFruit () {final String json = target ("fruit / search / strawberry"). Request () .get (String.class); assertThat (json, tartalmazString ("{\" név \ ": \" eper \ ", \" súly \ ": 20}")); }

4.2. Get Entity a JSON helyett

A választ közvetlenül is leképezhetjük egy erőforrás entitás osztályra - például:

 @Test public void givenFruitExists_whenSearching_thenResponseContainsFruitEntity () {final Fruit entitás = cél ("gyümölcs / keresés / eper"). assertEquals ("Gyümölcs neve:", "eper", entitás.getName ()); assertEquals ("Gyümölcs súlya", Integer.valueOf (20), entitás.getWeight ()); }

Ezúttal megadjuk azt a Java-típust, amelyre a válasz entitás átalakításra kerül a kap módszer - a Gyümölcs tárgy.

5. A POST tesztelése az erőforrások létrehozása érdekében

Új erőforrás létrehozása érdekében az API-ban - jól fogjuk használni a POST kéréseket. A következő szakaszban megtudhatjuk, hogyan tesztelhetjük az API-t.

5.1. Post Plain JSON

Kezdjük egy egyszerű JSON karakterlánc közzétételével, hogy teszteljük egy új gyümölcsforrás létrehozását:

@Test public void givenCreateFruit_whenJsonIsCorrect_thenResponseCodeIsCreated () {Response response = target ("fruit / created"). Request () .post (Entity.json ("{\" name \ ": \" eper \ ", \" weight \ ": 20} ")); assertEquals ("A Http válasznak 201-nek kell lennie, Status.CREATED.getStatusCode (), response.getStatus ()); assertThat (response.readEntity (String.class), tartalmazString ("Mentett gyümölcs: Gyümölcs [név: eper szín: null]")); }

A fenti példában a post módszer, amely egy Entitás objektum paraméter. Használjuk a kényelmes json metódus egy entitás létrehozására a megfelelő JSON karakterláncból.

5.2. Jogszabály helyett JSON

Amint a get kéréseknél már láthattuk, közvetlenül is közzétehetünk egy erőforrás entitás osztályt - például:

@Test public void givenCreateFruit_whenFruitIsInvalid_thenResponseCodeIsBadRequest () {Fruit fruit = new Fruit ("Blueberry", "purple"); gyümölcs.setSúly (1); Válasz válasz = cél ("gyümölcs / létrehozás"). Kérelem (MediaType.APPLICATION_JSON_TYPE) .post (Entity.entity (gyümölcs, MediaType.APPLICATION_JSON_TYPE)); assertEquals ("A Http válasznak 400-nak kell lennie, 400, response.getStatus ()"; assertThat (response.readEntity (String.class), tartalmazzaString ("A gyümölcs súlyának legalább 10-nek kell lennie")); }

Ezúttal a entitás módszer a Fruit entitás közzétételére, és a média típusát is adja meg JSON néven.

5.3. Űrlapbeküldés a POST használatával

Utolsó hozzászólási példánkban megtudhatjuk, hogyan lehet tesztelni az űrlap beküldését postai kérelem útján:

@Test public void givenCreateFruit_whenFormContainsNullParam_thenResponseCodeIsBadRequest () {Form form = new Form (); form.param ("név", "alma"); form.param ("color", null); Válasz válasza = cél ("gyümölcs / létrehozás"). Kérelem (MediaType.APPLICATION_FORM_URLENCODED) .post (Entity.form (képernyő)); assertEquals ("A Http válasznak 400-nak kell lennie, 400, response.getStatus ()"; assertThat (response.readEntity (String.class), tartalmazzaString ("A gyümölcs színe nem lehet null")); }

Hasonlóképpen használjuk a Entitás osztály, de ezúttal át kell adni egy űrlapot, amely számos paramétert tartalmaz a hozzászólási kérelemhez.

6. Egyéb HTTP igék tesztelése

Néha más HTTP-végpontokat is tesztelnünk kell, például a PUT és a DELETE elemeket. Ez természetesen tökéletesen lehetséges a Jersey Test Framework használatával.

Lássunk egy egyszerű PUT példát:

@Test public void givenUpdateFruit_whenFormContainsBadSerialParam_thenResponseCodeIsBadRequest () {Form form = new Form (); form.param ("sorozat", "2345-2345"); Válaszválasz = cél ("gyümölcs / frissítés"). Kérelem (MediaType.APPLICATION_FORM_URLENCODED) .put (Entity.form (képernyő)); assertEquals ("A Http válasznak 400-nak kell lennie, 400, response.getStatus ()"; assertThat (response.readEntity (String.class), tartalmazzaString ("A gyümölcs sorozatszáma érvénytelen")); }

Miután felhívtuk a kérés metódust, bármely HTTP metódust meghívhatunk az aktuális kérelemobjektumra.

7. További jellemzők

A Jersey tesztkeret számos további konfigurációs tulajdonságot tartalmaz, amelyek elősegíthetik a hibakeresést és a tesztelést.

A következő példában megnézzük, hogyan lehet programozottan engedélyezni egy adott névvel rendelkező szolgáltatást:

a FruitResourceIntegrationTest nyilvános osztály kiterjeszti a JerseyTestet {@Orride védett alkalmazás konfigurálása () {enable (TestProperties.LOG_TRAFFIC); engedélyezés (TestProperties.DUMP_ENTITY); // ...

Amikor tesztelés alatt létrehozzuk és konfiguráljuk a Jersey alkalmazásunkat. További tulajdonságokat is engedélyezhetünk. Ebben az esetben két naplózási tulajdonságot engedélyezünk - LOG_TRAFFIC és DUMP_ENTITYamely hasznos további naplózási és hibakeresési információkat nyújt a tesztfuttatások során.

8. Támogatott konténerek

Mint már említettük, a Jersey Test Framework tesztek írásakor használt defacto konténer a Grizzly. Számos más konténer azonban támogatott:

  • In-Memory tároló
  • HttpServer az Oracle JDK-tól
  • Egyszerű tároló (org.simpleframework.http
  • Mólótartály (org.eclipse.jetty)

A tárolók konfigurálásával kapcsolatos további információkért tekintse meg az itt található dokumentációt.

9. Következtetés

Összefoglalva, ebben az oktatóanyagban feltártuk a Jersey Test Framework-et. Először azzal kezdtük, hogy bemutattuk a Jersey Test Framework konfigurálását, majd láttuk, hogyan kell tesztet írni egy nagyon egyszerű API-ra.

A következő szakaszban láttuk, hogyan kell teszteket írni a különféle GET és POST API végpontokhoz. Végül megvizsgáltunk néhány további funkciót és a Jersey Test Framework által támogatott tárolókat.

Mint mindig, a cikk teljes forráskódja elérhető a GitHubon.


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