streamalism.org

1. Bevezetés

Ebben a cikkben gyorsan áttekintjük a JBehave-t, majd a REST API tesztelésére összpontosítunk BDD szempontból.

2. JBehave és BDD

A JBehave egy viselkedésalapú fejlesztési keretrendszer. Intuitív és hozzáférhető módon kívánja biztosítani az automatizált elfogadási tesztet.

Ha még nem ismeri a BDD-t, érdemes kezdeni ezzel a cikkel, amely egy másik BDD-tesztelési keretrendszerről szól - az Uborka, amelyben bemutatjuk a BDD általános szerkezetét és jellemzőit.

A többi BDD keretrendszerhez hasonlóan a JBehave is a következő fogalmakat fogadja el:

• Történet - az üzleti funkcionalitás automatikusan futtatható növekedését jelenti, egy vagy több forgatókönyvet tartalmaz
• Forgatókönyvek - konkrét példákat képviselnek a rendszer viselkedésére
• Lépések - a tényleges viselkedést képviselik a klasszikus BDD kulcsszavak használatával: Adott, Mikor és Azután

Tipikus forgatókönyv lenne:

Előfeltétel adott, ha egy esemény bekövetkezik, akkor az eredményt rögzíteni kell

A forgatókönyv minden lépése megfelel a JBehave feljegyzésének:

• @Adott: kezdeményezze a kontextust
• @Mikor: hajtsa végre a műveletet
• @Azután: tesztelje a várható eredményt

3. Maven-függőség

Ahhoz, hogy a JBehave-t felhasználhassuk maven projektünkben, a jbehave-core függőséget bele kell foglalni a pom:

 org.jbehave jbehave-core 4.1 teszt 

4. Gyors példa

A JBehave használatához a következő lépéseket kell végrehajtanunk:

1. Írj egy felhasználói történetet
2. A felhasználói sztoritól a Java kódig történő lépések leképezése
3. Konfigurálja a felhasználói történeteket
4. Futtassa a JBehave teszteket
5. Ellenőrizze az eredményeket

4.1. Sztori

Kezdjük a következő egyszerű történettel: „Felhasználóként szeretnék növelni egy számlálót, hogy a számláló értéke 1-vel növekedhessen”.

A történetet meghatározhatjuk a .sztori fájl:

Forgatókönyv: amikor a felhasználó növeli a számlálót, annak értéke 1-vel növekszik. Adott számláló És a számlálónak bármilyen integrált értéke van. Amikor a felhasználó növeli a számlálót, akkor a számláló értékének 1-rel nagyobbnak kell lennie, mint az előző érték

4.2. Térképezési lépések

A lépések ismeretében hajtsuk végre ezt a Java-ban:

public class NöveljeSteps {private int counter; private int previousValue; @Given ("számláló") public void aCounter () {} @Given ("a számlálónak bármilyen integrált értéke van") public void counterHasAnyIntegralValue () {counter = new Random (). NextInt (); előzőValue = számláló; } @ Amikor ("a felhasználó növeli a számlálót") a public void növekszikTheCounter () {számláló ++; } @Then ("a számláló értékének 1-rel nagyobbnak kell lennie, mint az előző érték") public void theValueOfTheCounterMustBe1Greater () {assertTrue (1 == számláló - előzőValue); }}

Emlékezz arra az annotációkban szereplő értéknek pontosan meg kell egyeznie a leírással.

4.3. A történetünk beállítása

A lépések végrehajtásához fel kell állítanunk a történet színpadát:

public class Az UpseStoryLiveTest kiterjeszti a JUnitStories {@Override nyilvános konfigurációs konfigurációját () {return new MostUsefulConfiguration () .useStoryLoader (new LoadFromClasspath (this.getClass ())) .useStoryReporterBuilder (new StoryReporterBuilder () .withCodeLrom () .withCodeLrom ) .Formátumok (KONZOL) segítségével; } @Orride public InjectableStepsFactory stepsFactory () {return new példányStepsFactory (konfiguráció (), új NövekedésSteps ()); } @Orride protected storyPaths List () {return Arrays.asList ("növekedés.történet"); }}

Ban ben storyPaths (), mi biztosítjuk .sztori a fájl elérési útját a JBehave elemzi. A tényleges lépések végrehajtását a stepsFactory (). Aztán be konfiguráció (), a történetbetöltő és a történetjelentés megfelelően van konfigurálva.

Most, hogy minden készen állunk, egyszerűen futással kezdhetjük a történetünket: mvn tiszta teszt.

4.4. A teszt eredményeinek áttekintése

Teszteredményünket a konzolon láthatjuk. Mivel tesztjeink sikeresen teljesültek, a kimenet megegyezik a történetünkkel:

Forgatókönyv: amikor a felhasználó növeli a számlálót, annak értéke 1-gyel nő

Ha elfelejtjük végrehajtani a forgatókönyv bármely lépését, a jelentés erről értesít minket. Mondjuk, hogy nem hajtottuk végre a @Mikor lépés:

Forgatókönyv: amikor a felhasználó növeli a számlálót, annak értéke 1-gyel nő )

@When ("a felhasználó növeli a számlálót") @ Függőben lévő nyilvános void amikor TheUserIncreasesTheCounter () {// PENDING}

A jelentés szerint a @Mikor folyamatban van egy lépés, és emiatt a @Azután lépést nem hajtják végre.

Mi van, ha a @Then lépésünk nem sikerül? A hibát azonnal észrevehetjük a jelentésben:

Forgatókönyv: amikor a felhasználó növeli a számlálót, annak értéke 1-vel növekszik. Adott számláló És a számlálónak bármilyen integrált értéke van, amikor a felhasználó növeli a számlálót. A számláló értékének 1-gyel nagyobbnak kell lennie, mint az előző érték (FAILED) (java. lang.AssertionError)

5. A REST API tesztelése

Most már megértettük az alapokat JBhave; meglátjuk, hogyan tesztelhetünk vele egy REST API-t. Tesztjeink az előző cikkünkön alapulnak, amely a REST API Java tesztelésével foglalkozik.

Ebben a cikkben teszteltük a GitHub REST API-t, és elsősorban a HTTP válaszkódra, a fejlécekre és a hasznos terhelésre összpontosítottunk. Az egyszerűség kedvéért három külön történetbe írhatjuk őket.

5.1. Az állapotkód tesztelése

A történet:

Forgatókönyv: amikor egy felhasználó egy nem létező felhasználót ellenőriz a github-on, a github 'nem található' választ ad meg. Adott github felhasználói profil api és véletlenszerű nem létező felhasználónév, amikor a véletlenszerű felhasználót keresem az api-n keresztül. Amikor az eugenp1-et keresem az api-n keresztül, akkor a github válaszol: 404 nem található, amikor az eugenp2-t keresem az api-n keresztül, majd a github válaszol: 404 nem található

A lépések:

public class GithubUserNotFoundSteps {private String api; privát String nonExistentUser; privát int githubResponseCode; @Given ("github felhasználói profil api") public void givenGithubUserProfileApi () {api = "//api.github.com/users/%s"; } @Given ("véletlenszerű, nem létező felhasználónév") public void givenANonexistentUsername () {nonExistentUser = randomAlphabetic (8); } @When ("A véletlenszerű felhasználót keresem az api-n keresztül") public void whenILookForTheUserViaTheApi () IOException dobja {githubResponseCode = getGithubUserProfile (api, nonExistentUser) .getStatusLine () .getStatusCode (); } @When ("$ felhasználót keresek az api-n keresztül") public void whenILookForSomeNonExistentUserViaTheApi (String user) IOException {githubResponseCode = getGithubUserProfile (api, user) .getStatusLine () .getStatusCode (); } @Then ("github válasz: 404 nem található") public void thenGithubRespond404NotFound () {assertTrue (SC_NOT_FOUND == githubResponseCode); } // ...}

Figyelje meg, hogy a megvalósítás lépései során a paraméter-injektálás funkciót használtuk. A lépésjelöltből kivont argumentumokat természetes sorrendben párosítjuk az annotált Java módszer paramétereivel.

Emellett a megjegyzéssel ellátott megnevezett paraméterek is támogatottak:

@ Amikor ("A $ felhasználónév keresése az api-n keresztül történik") public void whenILookForSomeNonExistentUserViaTheApi (@Named ("felhasználónév") String user) dobja az IOException-t

5.2. A hordozótípus tesztelése

Íme egy egyszerű MIME típusú tesztelő történet:

Forgatókönyv: amikor egy felhasználó érvényes felhasználói profilt ellenőriz a githubon, a github válaszolni fog a json adataira. Adott github felhasználói profil api és érvényes felhasználónév, amikor a felhasználót az api segítségével keresem

És itt vannak a lépések:

public class GithubUserResponseMediaTypeSteps {private String api; private String validUser; privát String mediaType; @Given ("github felhasználói profil api") public void givenGithubUserProfileApi () {api = "//api.github.com/users/%s"; } @Given ("érvényes felhasználónév") public void givenAValidUsername () {validUser = "eugenp"; } @When ("A felhasználót az api-n keresztül keresem") public void whenILookForTheUserViaTheApi () IOException {mediaType = ContentType .getOrDefault (getGithubUserProfile (api, validUser) .getEntity ()) .getMimeType (); } @Then ("github reagáljon a json típusú adatokra") public void thenGithubRespondDataOfTypeJson () {assertEquals ("application / json", mediaType); }}

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

Aztán az utolsó történet:

Forgatókönyv: amikor a felhasználó egy érvényes felhasználói profilt ellenőriz a github-on, a github válaszának jsonnak tartalmaznia kell egy bejelentkezési terhelést ugyanazzal a felhasználónévvel. Adott github felhasználói profil api Ha az eugenp-t keresem az api-n keresztül.

És az egyszerű lépések megvalósítása:

public class GithubUserResponsePayloadSteps {private String api; privát GitHubUser erőforrás; @Given ("github felhasználói profil api") public void givenGithubUserProfileApi () {api = "//api.github.com/users/%s"; } @When ("$ felhasználót keresek az api-n keresztül") public void, amikor aILookForEugenpViaTheApi (String felhasználó) az IOException-t dobja {HttpResponse httpResponse = getGithubUserProfile (api, felhasználó); erőforrás = RetrieveUtil.retrieveResourceFromResponse (httpResponse, GitHubUser.class); } @Then ("a github válasza" belépési "terhelést tartalmaz, mint a $ username") public void thenGithubsResponseContainsAloginPayloadSameAsEugenp (String felhasználónév) {assertThat (felhasználónév, Matchers.is (resource.getLogin ())); }}

6. Összefoglalás

Ebben a cikkben röviden bemutattuk a JBehave-t és megvalósítottuk a BDD stílusú REST API teszteket.

Egyszerű Java tesztkódunkhoz képest a JBehave alkalmazásával végrehajtott kód sokkal egyértelműbb és intuitívabb, a teszt eredményjelentése pedig sokkal elegánsabb.

Mint mindig, a példakód megtalálható a Github projektben.