Cucumber-skenaariorunkojen toteuttaminen BDD-kehyksissä

Käyttäytymislähtöinen kehitys (BDD) on ketterä ohjelmistokehityskäytäntö, joka parantaa sidosryhmien ja kehittäjien välistä yhteistyötä käyttämällä yksinkertaista, toimialakohtaista kieltä järjestelmän käyttäytymisen kuvaamiseen. 

Yksi BDD:n tehokkaimmista työkaluista on Cucumber, jota käytetään selkeiden määritysten kirjoittamiseen. Sitä voidaan käyttää myös testaukseen useimpien yleisesti käytettyjen ohjelmointikielten, kuten Javan, Pythonin tai C#:n, kanssa, ja se voidaan integroida käyttöliittymäkehyksiin, kuten Seleniumiin, tai sitä voidaan käyttää API-testaukseen.

Skenaariohahmotelmat ovat osa Cucumberin Gherkin-syntaksia, jota käytetään suoritettavien määritysten kirjoittamiseen. Toisin kuin tavalliset skenaariot, jotka määrittelevät yhden konkreettisen esimerkin, skenaariohahmotelmien avulla voidaan määritellä useita esimerkkejä taulukkomuodossa. 

Skenaarion ja skenaariohahmotelmien erot

Cucumberin skenaariot edustavat testitapausta, joka on kirjoitettu perusmuodossa oletus-kun-silloin. Gherkin-kielen ansiosta nämä testiskenaariot voidaan kirjoittaa selkeällä englannilla (ja muilla kielillä), joten myös henkilöt, joilla ei ole teknistä taustaa, voivat ymmärtää niitä ja jopa kirjoittaa niitä. Vaiheiden toteutuksen määrittelevät vaiheiden määrittelyt luodaan erillisiin tiedostoihin. 

Joidenkin toimintojen kohdalla on järkevää toistaa sama skenaario erilaisilla testitiedoilla – tunnet tämän todennäköisesti dataohjattuna testauksena. Cucumberissa tämä tehdään käyttämällä skenaariohahmotelmaa ja esimerkkitaulukkoa, joka sisältää käytettävät tietojoukot. Jokainen esimerkki lasketaan erilliseksi testiksi.  

Cucumberin skenaariohahmotelman syntaksi

Tyypillinen Cucumber-projekti sisältää ominaisuustiedostoja, joissa Cucumber-testit määritellään, sekä vaiheiden määrittelytiedostoja, joissa vaiheiden toteutukset sijaitsevat. 

Ominaisuustiedoston tulisi kuvata vaatimusmäärittely ja sen testaamiseen käytettävät skenaariot. Yksinkertaisen Cucumber-skenaarion perussyntaksi on seuraava:

Skenaario voi sisältää myös muuttujia, joita käsitellään sellaisina vaiheiden määrittelyssä.

Arvoja “test”, “virheellinen” ja “Virheellinen kirjautuminen” käsitellään muuttujina. Katsotaan nyt, mitä tapahtuu, kun haluamme kokeilla annettujen muuttujien erilaisia yhdistelmiä – voisimme päätyä useisiin skenaarioihin, jotka ovat muuttujien arvoja lukuun ottamatta identtisiä, tai käyttää skenaariohahmotelmaa, jonka avulla voimme käyttää taulukkoa erilaisten datayhdistelmien määrittämiseen:

Datayhdistelmä kirjoitetaan “Esimerkit”-avainsanan alle taulukon sisälle. Taulukoiden otsikot ovat muuttujien nimiä, ja kukin rivi edustaa datayhdistelmää. Kutakin Cucumber-ominaisuuteen kuuluvaa esimerkkiä käsitellään yksittäisenä testitapauksena. 

Esimerkkitaulukot ja datataulukot

Esimerkit ja datataulukot saattavat näyttää samanlaisilta, mutta niillä on eri tarkoitukset. Tärkein ero on, että esimerkkejä käytetään dataohjattujen skenaarioiden toteuttamiseen, kun taas datataulukoita käytetään silloin, kun skenaarion vaiheissa täytyy käyttää useita muuttujia.

Datataulukkoa voidaan käyttää seuraavasti:

tai näin:

Datataulukot ovat erityisen hyödyllisiä, kun vaiheet edellyttävät useita muuttujia, ja niitä on helpompi lukea kuin silloin, kun jokainen arvo kirjoitetaan vaiheen sisään.  

Datataulukoiden ja skenaariomallin käyttäminen 

Datataulukot ja skenaariomallit voivat toimia myös yhdessä. Muuttujan nimi annetaan datataulukossa, minkä jälkeen sitä käytetään uudelleen esimerkkitaulukossa.

Skenaariomallien käytön edut

Skenaariomalleja voidaan pitää testitapauksen ”mallipohjana”. Kun ne toteutetaan testiautomaatiokehyksessä, niiden todellinen tehtävä on suorittaa sama skenaario eri tietojoukoilla.

Etuna on Gherkin-rivien ja toiston vähäisempi määrä. Tämä tarkoittaa, että aina kun yhteiseen skenaarioon tarvitaan muutos, se voidaan tehdä vain kerran, ja muutos otetaan käyttöön kaikissa testidatayhdistelmissä.

Toinen skenaariomallien etu on, että ne voivat tarjota laajemman kattavuuden vähäisellä työllä. Uuden testin lisäämiseksi tarvitsee lisätä vain uusi esimerkkirivi.

Skenaariomallien kirjoittamisen parhaat käytännöt

• Hyödynnä todellista dataa: Tiimi ei todennäköisesti jätä reunaehtoja tai piilotettua tietoa huomiotta, kun se käyttää tosielämän käyttötapauksia toiminnan ymmärtämiseen.
• Viestikää tavoite liiketoimintaterminologiaa käyttäen, jotta tiimin tekniset ja ei-tekniset sidosryhmät ymmärtävät toisiaan paremmin.
• Selitä tarkoituksesi sen sijaan, että kuvaisit, miten se toteutetaan; vaiheiden kuvausten tulisi olla mahdollisimman vähän teknisiä. Niiden tulisi keskittyä enemmän järjestelmän toimintoihin kuin sen toimintaan.
• Säilytä vain tarpeellinen: Jotta skenaario pysyy kiinnostavana kaikille osallistujille, älä kuormita sitä tarpeettomilla vaiheilla.

Tärkeimmät huomiot

Cucumber on erinomainen yhteistyöväline ei-teknisten henkilöiden, kehittäjien ja testaajien välillä. Se on BDD-työkalu, joka tarjoaa kirjalliset määrittelyt ja jota voidaan käyttää testaamiseen. Erilaisten vaatimusten havainnollistamiseksi voidaan kirjoittaa useita skenaarioita.

Skenaariomallia kannattaa käyttää erillisten arvojoukkojen kanssa, jotka annetaan esimerkkitaulukon kautta, kun skenaarioissa on samat vaiheet mutta ne edellyttävät erilaisia data-arvoja syötteinä tai tulosteina.

Tilaa The CTO Clubin uutiskirje, niin saat lisää näkemyksiä.