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:
- Küldjön HTTP GET kérést a következő címre: / / greetings / hi
- Ellenőrizze a HTTP állapotkódot és a tartalomtípus válaszfejlécét
- 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.