REST API tesztelése uborkával

1. Áttekintés

Ez az oktatóanyag bemutatja az uborkát, amely a felhasználók elfogadásának teszteléséhez gyakran használt eszköz, és annak használatát a REST API tesztekben.

Ezen túlmenően, hogy a cikk önálló és független legyen a külső REST szolgáltatásoktól, a WireMock-ot fogjuk használni, egy csökönyös és gúnyos webszolgáltatási könyvtárat. Ha többet szeretne megtudni erről a könyvtárról, olvassa el a WireMock bevezetőjét.

2. Uborka - az uborka nyelve

Az Uborka egy olyan tesztelési keretrendszer, amely támogatja a Viselkedésvezérelt fejlesztést (BDD), lehetővé téve a felhasználók számára, hogy az alkalmazás műveleteit egyszerű szövegben határozzák meg. A Gherkin Domain Specific Language (DSL) alapján működik. A Gherkin ezen egyszerű, de hatékony szintaxisa lehetővé teszi a fejlesztőknek és a tesztelőknek, hogy összetett teszteket írjanak, miközben még a nem technikai felhasználók számára is érthetőek maradnak.

2.1. Bevezetés a uborka

A Gherkin egy vonal-orientált nyelv, amely vonalvégeket, behúzásokat és kulcsszavakat használ a dokumentumok meghatározásához. Minden nem üres sor általában egy Gherkin kulcsszóval kezdődik, amelyet egy tetszőleges szöveg követ, amely általában a kulcsszó leírása.

A teljes szerkezetet egy fájlba kell írni a funkció az uborkának el kell ismernie.

Itt van egy egyszerű Gherkin dokumentum példa:

Jellemző: A kívánt funkcionalitás rövid leírása Forgatókönyv: Üzleti helyzet Előfeltételt és újabb előfeltételt adva Ha egy esemény bekövetkezik És egy másik esemény is bekövetkezik Akkor tesztelhető eredmény érhető el és valami más is elkészül

A következő szakaszokban leírjuk a Gherkin-struktúra néhány legfontosabb elemét.

2.2. Funkció

Gherkin fájlt használunk arra, hogy leírjuk az alkalmazást, amelyet tesztelni kell. A fájl tartalmazza a Funkció kulcsszó a legelején, utána a tulajdonság neve ugyanazon a soron és egy opcionális leírás, amely alatta több sort is átívelhet.

Az uborka elemző az egész szöveget kihagyja, a Funkció kulcsszó, és csak dokumentáció céljából tartalmazza.

2.3. Forgatókönyvek és lépések

A Gherkin struktúra egy vagy több forgatókönyvből állhat, amelyeket a Forgatókönyv kulcsszó. A forgatókönyv alapvetően egy teszt, amely lehetővé teszi a felhasználók számára, hogy ellenőrizzék az alkalmazás képességeit. Le kell írnia egy kezdeti kontextust, az esetlegesen bekövetkező eseményeket és az események által létrehozott várható eredményeket.

Ezeket a lépéseket az öt kulcsszó egyikével azonosított lépésekkel hajtják végre: Adott, Mikor, Azután, És, és De.

  • Adott: Ezzel a lépéssel a rendszert egy jól körülhatárolható állapotba hozzuk, mielőtt a felhasználók elkezdnék az alkalmazást. A Adott záradék a felhasználási eset előfeltételének tekinthető.
  • Mikor: A Mikor lépés az alkalmazással bekövetkező esemény leírására szolgál. Ez lehet a felhasználók által végrehajtott művelet, vagy egy másik rendszer által kiváltott esemény.
  • Azután: Ez a lépés a teszt várható eredményének meghatározása. Az eredménynek a tesztelt tulajdonság üzleti értékeihez kell kapcsolódnia.
  • És és De: Ezek a kulcsszavak felhasználhatók a fenti lépés kulcsszavainak cseréjére, ha több, azonos típusú lépés van.

Az uborka valójában nem különbözteti meg ezeket a kulcsszavakat, azonban továbbra is ott vannak, hogy a funkciót olvashatóbbá és következetesebbé tegyék a BDD struktúrával.

3. Uborka-JVM megvalósítás

Az uborka eredetileg a Ruby nyelven íródott, és a Java-ba került a Cucumber-JVM implementációval, amely a szakasz tárgya.

3.1. Maven-függőségek

A Cucumber-JVM Maven projektben történő felhasználásához a következő függőséget kell felvenni a POM-ba:

 io. uborka uborka-java 6.8.0 teszt 

A JUnit uborka tesztelésének megkönnyítése érdekében még egy függőségre van szükségünk:

 io. uborka uborka-junit 6.8.0 

Alternatív megoldásként használhatunk egy másik műtárgyat is a Java 8 lambda-kifejezéseinek kihasználására, amelyekre ez az oktatóanyag nem tér ki.

3.2. Lépésdefiníciók

A uborka-forgatókönyvek haszontalanok lennének, ha azokat nem cselekvésekké alakítanák át, és itt lépnek fel a lépésdefiníciók. Alapvetően a lépésdefiníció egy kommentált Java-módszer csatolt mintával, amelynek feladata a Gherkin-lépések egyszerű szövegben konvertálása futtatható kódgá. A funkciódokumentum elemzése után az uborka olyan lépésdefiníciókat keres, amelyek megfelelnek az előre definiált Gherkin-lépéseknek.

Annak érdekében, hogy világosabb legyen, nézzük meg a következő lépést:

Tekintettel arra, hogy tanfolyamot regisztráltam Baeldungban

És egy lépésdefiníció:

@Given ("Bejegyeztem egy tanfolyamot Baeldungba") public void verifyAccount () {// módszer implementációja}

Amikor az uborka elolvassa az adott lépést, olyan lépések meghatározásait keresi, amelyek annotációs mintái megegyeznek a Gherkin szöveggel.

4. Tesztek készítése és futtatása

4.1. Funkciófájl írása

Kezdjük a forgatókönyvek és lépések deklarálásával egy fájlban, amelynek neve végződik .funkció kiterjesztés:

Jellemző: A REST API tesztelése A felhasználóknak képesnek kell lenniük arra, hogy GET és POST kéréseket nyújtsanak be egy webszolgáltatáshoz, amelyet a WireMock forgatókönyv képvisel: Adattöltés egy webszolgáltatásba, amikor a felhasználók adatokat töltenek fel egy projektre. Ezután a szervernek kell kezelnie és visszaadnia a siker állapotát Forgatókönyv: Adathívás egy webszolgáltatásból Ha a felhasználók információt akarnak szerezni az „Uborka” projektről, akkor a kért adatok visszaküldődnek

Ezt a fájlt most egy elnevezett könyvtárba mentjük Funkció, azzal a feltétellel, hogy a könyvtár futás közben kerül betöltésre az osztályútvonalra, pl. src / main / resources.

4.2. A JUnit beállítása az uborka használatához

Annak érdekében, hogy a JUnit tisztában legyen az uborkával és olvassa a funkciófájlokat a futtatás során, a Uborka osztályt kell deklarálni Futó. Azt is meg kell mondanunk a JUnit-nak, hogy keressen funkciófájlokat és lépésdefiníciókat.

@RunWith (Cucumber.class) @CucumberOptions (features = "classpath: Feature") public class CucumberIntegrationTest {}

Mint láthatja, a jellemzők eleme UborkaOption megkeresi a korábban létrehozott funkciófájlt. Egy másik fontos elem, az ún ragasztó, utat ad a lépésdefiníciókhoz. Ha azonban a teszteset és a lépésdefiníciók ugyanabban a csomagban vannak, mint ebben az oktatóanyagban, akkor az elem eldobható.

4.3. Írás lépésdefiníciók

Amikor az uborka elemzi a lépéseket, a Gherkin kulcsszavakkal kiegészített módszereket keresi az egyező lépésdefiníciók megkeresésére.

A lépésmeghatározás kifejezése lehet reguláris kifejezés vagy uborka kifejezés. Ebben az oktatóanyagban az uborka kifejezéseket fogjuk használni.

Az alábbiakban egy módszer felel meg, amely teljes mértékben megfelel egy Gherkin lépésnek. A módszert az adatok REST webszolgáltatásba történő feladására fogják használni:

@ Amikor ("a felhasználók adatokat töltenek fel egy projektre") public void usersUploadDataOnAProject () dobja az IOException-t {}

És itt van egy módszer, amely illeszkedik egy Gherkin lépéshez, és egy argumentumot vesz ki a szövegből, amelyet felhasználva információkat szerezhet a REST webszolgáltatásból:

@ Amikor ("a felhasználók információt akarnak kapni a {string} projektről") public void usersGetInformationOnAProject (String projectName) dobja az IOException-t {}

Mint láthatja, a usersGetInformationOnAProject módszer a Húr argumentum, amely a projekt neve. Ezt az érvet a {húr} az annotációban és idefelé megfelel Uborka a lépésszövegben.

Alternatív megoldásként használhatunk reguláris kifejezést:

@ Amikor ("^ a felhasználók információt akarnak szerezni a '(. +)' Projektről $") public void usersGetInformationOnAProject (String projectName) dobja az IOException-t {}

Megjegyzés: a ‘^' és ‘$' amelyek ennek megfelelően jelzik a regex kezdetét és végét. Mivel ‘(.+)' megfelel a Húr paraméter.

Mindkét fenti módszer munkakódját a következő szakaszban közöljük.

4.4. Tesztek készítése és futtatása

Először egy JSON struktúrával kezdjük, amely szemlélteti a szerverre POST kéréssel feltöltött és az ügyfélnek GET segítségével letöltött adatokat. Ezt a struktúrát menti a jsonString mezőben, és az alább látható:

{"testing-framework": "uborka", "támogatott nyelv": ["Ruby", "Java", "Javascript", "PHP", "Python", "C ++"], "website": "uborka. io "}

A REST API bemutatásához WireMock szervert használunk:

WireMockServer wireMockServer = új WireMockServer (opciók (). DynamicPort ());

Ezenkívül az Apache HttpClient API-t fogjuk használni a kiszolgálóhoz való csatlakozáshoz használt kliens képviseletére:

CloseableHttpClient httpClient = HttpClients.createDefault ();

Most térjünk át a tesztkód írására a lépésdefiníciókban. Tesszük ezt a usersUploadDataOnAProject módszer először.

A kiszolgálónak futnia kell, mielőtt az ügyfél csatlakozik hozzá:

wireMockServer.start ();

A WireMock API használata a REST szolgáltatás elcsúfításához:

configureFor ("localhost", wireMockServer.port ()); stubFor (post (urlEqualTo ("/ create")) .withHeader ("content-type", equalTo ("application / json")) .withRequestBody (tartalmazza ("testing-framework")) .willReturn (aResponse (). withStatus (200)));

Most küldjön egy POST kérést a jsonString a szervernek fentebb deklarált mező:

HttpPost request = new HttpPost ("// localhost:" + wireMockServer.port () + "/ create"); StringEntity entitás = new StringEntity (jsonString); request.addHeader ("content-type", "application / json"); request.setEntity (entitás); HttpResponse response = httpClient.execute (kérés);

A következő kód azt állítja, hogy a POST kérést sikeresen megkapta és kezelte:

assertEquals (200, response.getStatusLine (). getStatusCode ()); ellenőrizze (postRequestedFor (urlEqualTo ("/ create")) .withHeader ("content-type", equalTo ("application / json")));

A kiszolgálónak le kell állnia a használat után:

wireMockServer.stop ();

A második módszer, amelyet itt alkalmazunk, az usersGetInformationOnAProject (String projectName). Az első teszthez hasonlóan el kell indítanunk a szervert, majd meg kell csonkítanunk a REST szolgáltatást:

wireMockServer.start (); configureFor ("localhost", wireMockServer.port ()); stubFor (get (urlEqualTo ("/ projektek / uborka")) .withHeader ("elfogadja", equalTo ("alkalmazás / json")) .willReturn (aResponse (). withBody (jsonString)));

GET-kérelem benyújtása és válasz fogadása:

HttpGet request = new HttpGet ("// localhost:" + wireMockServer.port () + "/ projects /" + projectName.toLowerCase ()); request.addHeader ("elfogad", "alkalmazás / json"); HttpResponse httpResponse = httpClient.execute (kérés);

Átváltjuk a httpResponse változó a Húr segítő módszerrel:

String responseString = convertResponseToString (httpResponse);

A konverziós segítő módszer megvalósítása itt található:

privát karakterlánc convertResponseToString (HttpResponse response) dobja az IOException {InputStream responseStream = response.getEntity (). getContent (); Szkenner szkenner = új szkenner (responseStream, "UTF-8"); String responseString = szkenner.useDelimiter ("\ Z"). Következő (); scanner.close (); return responseString; }

Az alábbiak igazolják a teljes folyamatot:

assertThat (responseString, tartalmazString ("\" testing-framework \ ": \" uborka \ "")); assertThat (responseString, tartalmazString ("\" weboldal \ ": \" uborka.io \ "")); ellenőrizze (getRequestedFor (urlEqualTo ("/ projektek / uborka")) .withHeader ("elfogadja", equalTo ("alkalmazás / json")));

Végül állítsa le a szervert az előbb leírtak szerint.

5. Futási jellemzők párhuzamosan

Az Uborka-JVM natív módon támogatja a párhuzamos tesztfuttatást több szálon keresztül. A futók kivitelezéséhez a JUnit-ot a Maven Failsafe beépülő modullal együtt fogjuk használni. Alternatív megoldásként használhatjuk a Maven Surefire-t is.

A JUnit a funkciófájlokat párhuzamosan futtatja, nem pedig forgatókönyveket, ami azt jelenti egy szolgáltatásfájl összes forgatókönyvét ugyanaz a szál hajtja végre.

Adjuk hozzá a bővítmény konfigurációját:

 maven-failsafe-plugin $ {maven-failsafe-plugin.version} CucumberIntegrationTest.java Method 2 integrációs teszt 

Vegye figyelembe, hogy:

  • párhuzamos: lehet osztályok, módszerek, vagy mindkettő - esetünkben osztályok minden tesztosztály külön szálban fog futni
  • szálak száma: jelzi, hogy hány szálat kell lefoglalni ehhez a végrehajtáshoz

Ennyit kell tennünk az uborka funkciók párhuzamos futtatásáért.

6. Következtetés

Ebben az oktatóanyagban bemutattuk az uborka alapjait és azt, hogy ez a keretrendszer hogyan használja a Gherkin tartomány-specifikus nyelvet a REST API teszteléséhez.

Szokás szerint az ebben az oktatóanyagban bemutatott összes kódminta elérhető a GitHubon.


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