streamalism.org

1. Áttekintés

Ez az oktatóanyag a következők alapelveire és mechanikájára összpontosít egy REST API tesztelése élő integrációs tesztekkel (JSON hasznos teherrel).

A fő cél egy bevezetés bemutatása az API alapvető helyességének teszteléséhez - és a példákhoz a GitHub REST API legújabb verzióját fogjuk használni.

Belső alkalmazás esetében ez a fajta tesztelés a késõbbi lépésként fut a folyamatos integrációs folyamat során, és a REST API-t már a telepítése után elfogyasztja.

A REST erőforrás tesztelésekor általában néhány ortogonális felelősségre van szükség, amelyekre a teszteknek összpontosítaniuk kell:

• a HTTP válaszkód
• egyéb HTTP fejlécek válaszában
• a hasznos teher (JSON, XML)

Minden tesztnek csak egyetlen felelősségre kell összpontosítania, és egyetlen állítást kell tartalmaznia. A világos elkülönítésre való összpontosításnak mindig előnyei vannak, de az ilyen típusú fekete doboz végrehajtása során a tesztelés még fontosabb, mivel az általános tendencia az, hogy a legelején összetett tesztforgatókönyveket ír.

Az integrációs tesztek másik fontos szempontja a Az absztrakciós elv egyetlen szintje - a teszten belüli logikát magas szinten kell megírni. Az olyan részleteket, mint például a kérelem létrehozása, a HTTP-kérés elküldése a szerverre, az IO-val való foglalkozás stb., Nem inline, hanem segédprogramokkal kell végrehajtani.

2. Az állapotkód tesztelése

@Test public void givenUserDoesNotExists_whenUserInfoIsRetrieved_then404IsReceived () dobja a ClientProtocolException, IOException {// adott karakterlánc neve = RandomStringUtils.randomAlphabetic (8); HttpUriRequest kérés = új HttpGet ("//api.github.com/users/" + név); // Amikor HttpResponse httpResponse = HttpClientBuilder.create (). Build (). Végrehajtani (kérés); // Ezután assertThat (httpResponse.getStatusLine (). GetStatusCode (), equalTo (HttpStatus.SC_NOT_FOUND)); }

Ez egy meglehetősen egyszerű teszt - igazolja, hogy működik egy alapvető boldog út, anélkül, hogy túl sok bonyolultságot adna a tesztcsomaghoz.

Ha valamilyen okból kifolyólag nem sikerül, akkor nem kell más vizsgálatot végezni ezen az URL-en addig, amíg ezt nem javítják.

3. A hordozótípus tesztelése

@Test public void givenRequestWithNoAcceptHeader_whenRequestIsExecuted_thenDefaultResponseContentTypeIsJson () dobja a ClientProtocolException, IOException {// adott karakterláncot jsonMimeType = "application / json"; HttpUriRequest kérés = új HttpGet ("//api.github.com/users/eugenp"); // Amikor a HttpResponse response = HttpClientBuilder.create (). Build (). Execute (request); // Akkor String mimeType = ContentType.getOrDefault (response.getEntity ()). GetMimeType (); assertEquals (jsonMimeType, mimeType); }

Ez biztosítja, hogy a Válasz valóban tartalmaz JSON-adatokat.

Mint észrevehette, logikusan haladunk a teszteken - először a Válasz állapotkódja (annak biztosítása érdekében, hogy a kérés rendben legyen), majd a Válasz adathordozó típusa, és csak a következő tesztben nézzük meg a tényleges JSON hasznos terhet.

4. A JSON hasznos terhelésének tesztelése

@Test public void givenUserExists_whenUserInformationIsRetrieved_thenRetrievedResourceIsCorrect () dobja a ClientProtocolException, IOException {// adott HttpUriRequest kérést = új HttpGet ("//api.github.com/users/eugenp"); // Amikor a HttpResponse response = HttpClientBuilder.create (). Build (). Execute (request); // Akkor GitHubUser erőforrás = RetrieveUtil.retrieveResourceFromResponse (válasz, GitHubUser.class); assertThat ("eugenp", Matchers.is (erőforrás.getLogin ())); }

Ebben az esetben tudom, hogy a GitHub erőforrások alapértelmezett ábrázolása a JSON, de általában a Tartalom típus A válasz fejlécét a Elfogad a kérés fejléce - az ügyfél egy adott típusú ábrázolást kér a következőn keresztül: Elfogad, amelyet a szervernek tiszteletben kell tartania.

5. Segédprogramok a teszteléshez

A Jackson 2-t használjuk a nyers JSON karakterlánc típusbiztonsági Java-entitássá bontására:

public class GitHubUser {private String login; // szabványos mérőeszközök és beállítók}

Csak egy egyszerű segédprogramot használunk a tesztek tisztaságának, olvashatóságának és magas absztrakciós szintjének megőrzéséhez:

public static T retrieveResourceFromResponse (HttpResponse response, Class clazz) dobja az IOException {String jsonFromResponse = EntityUtils.toString (response.getEntity ()); ObjectMapper mapper = új ObjectMapper () .configure (DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, hamis); return mapper.readValue (jsonFromResponse, clazz); }

Figyelje meg, hogy Jackson figyelmen kívül hagyja azokat az ismeretlen tulajdonságokat, amelyeket a GitHub API küld nekünk - egyszerűen azért, mert a felhasználói erőforrások GitHubon való ábrázolása meglehetősen összetetté válik -, és itt nincs szükségünk ezekre az információkra.

6. Függőségek

A segédprogramok és tesztek a következő könyvtárakat használják, amelyek mind elérhetőek a Maven központjában:

• HttpClient
• Jackson 2
• Hamcrest (opcionális)

7. Következtetés

Ez csak egy része annak, aminek a teljes integrációs tesztkészletnek lennie kell. A tesztek a következőkre összpontosítanak a REST API alapvető helyességének biztosítása, anélkül, hogy bonyolultabb forgatókönyvekbe menne,

Például a következők nem tartoznak ide: az API felfedezhetősége, különböző reprezentációk fogyasztása ugyanazon erőforráshoz stb.

Ezeknek a példáknak és kódrészleteknek a megvalósítása megtalálható a Github-on - ez egy Maven-alapú projekt, ezért könnyen importálhatónak és futtathatónak kell lennie.