Behavior Driven Development cu JUnit 5. Partea a treia

Cea de-a treia parte a articolului nostru despre Behavior Driven Development cu JUnit 5.

4. Cum lucram in stilul BDD cu Cucumber si JUnit 5

In articolul nostru anterior, am lucrat in stilul TDD pentru a dezvolta aplicatia de flight-management pana la stadiul unde poate lucra cu trei tipuri de zboruri: economy, business, si premium. Mai mult decat atat, am implementat cerinta conform careia un pasager poate sa fie adaugat unui zbor doar o singura data.

Am introdus deja, intr-un mod discret, cateva elemente legate de stilul BDD. Putem sa citim cu usurinta modul in care functioneaza aplicatia urmarind testele care folosesc cuvintele cheie Se da, Cand si Apoi (Given/When/Then). Vom muta aplicatia pe BDD cu Cucumber si vom introduce si cateva functionalitati noi.

Cucumber este un framework de testare BDD. Descrie scenariile de aplicare intr-un limbaj simplu de inteles folosind Gherkin. Cucumber este usor de citit si inteles de catre toti stakeholderi din proiect si permite automatizari.

Principalele functionalitati ale Cucumber sunt:

• Scenarii sau exemple care descriu cerintele
• Un scenariu este definit prin intermediul unei liste de pasi care trebuie sa fie efectuati de Cucumber
• Cucumber executa codul care corespunde scenariilor, verifica daca software-ul urmeaza aceste scenarii si genereaza un raport care descrie succesul sau esecul fiecarui scenariu

Principalele functionalitati ale Gherkin sunt:

• Gherkin defineste reguli gramaticale simple care ii permit lui Cucumber sa inteleaga text in engleza simpla
• Gherkin documenteaza comportamentul sistemului. Cerintele sunt actualizate de fiecare data pentru ca sunt oferite prin scenarii care reprezinta specificatii live

Cucumber asigura faptul ca acceptance tests pot sa fie citite, scrise si intelese cu usurinta atat de catre persoane tehnice cat si de catre persoane non-tehnice. Acceptance tests au devenit un instrument de comunicare intre diferitii stakeholderi din cadrul proiectului.

Un acceptance test in Cucumber arata asa:

Se da un zbor economy
Cand avem un pasager obisnuit
Apoi poate sa fie adaugat sau scos dintr-un zbor economy

Din nou, observam cuvintele cheie Se da/Cand/Apoi pe care le folosim pentru a descrie un scenariu. Cuvinte pe care le-am introdus anterior cand lucram cu JUnit 5. De acum incolo nu le vom folosi doar pentru etichetare: Cucumber interpreteaza propozitii care incep cu aceste cuvinte si genereaza metode pe le adnoteaza folosind adnotarile @Given, @When, si @Then.

Acceptance tests sunt scrise in Cucumber feature files. Un feature file este un punct de intrare in testele Cucumber; in fisier, descriem testele noastre in Gherkin. Un feature file poate sa contina unul sau mai multe scenarii.

Putem sa incepem sa planificam modul in care vom lucra cu Cucumber in proiect. Vom introduce mai intai Cucumber dependencies in configurarea Maven existenta. Vom crea o functionalitate Cucumber si vom genera scheletul folosind teste Cucumber. Apoi, vom transfera testele JUnit 5 existente pentru a umple acest schelet de test generat de Cucumber.

<dependency>

<groupId>info.cukes</groupId>

<artifactId>cucumber-java</artifactId>

<version>1.2.5</version>

<scope>test</scope>

</dependency>

<dependency>

<groupId>info.cukes</groupId>

<artifactId>cucumber-junit</artifactId>

<version>1.2.5</version>

<scope>test</scope>

</dependency>

In codul de mai sus, introducem cele doua Maven dependencies necesare: cucumber-java si cucumber-junit.

Vom incepe sa creeam functionalitati Cucumber. Folosim structura standard de foldere Maven si introducem functionalitatile in folderul test/resources. Cream folderul test/resources/features si in el cream fisierul passengers_policy.feature (figure 1).

Fig 1 Noul fisier Cucumber passenger_policy.feature este creat in folderul test/resources/features, folosind regulile Maven.

Urmarim sintaxa Gherkin si introducem o functionalitate denumita Passengers Policy, impreuna cu o descriere scurta legata de ce ar trebui sa faca. Apoi folosim sintaxa Gherkin pentru a scrie scenariile.

Functionalitate: Passengers Policy
Compania urmareste o politica legata de adaugarea si indepartarea pasagerilor, in functie de tipul pasagerului si tipul zborului

Scenariu: Zbor economy, pasager obisnuit
Se da un zbor economy
Cand avem un pasager obisnuit
Apoi putem sa il adaugam sau sa il scoatem din cadrul unui zbor economy
Si nu putem adauga un pasager obisnuit la un zbor economy de mai multe ori

Scenario: Zbor economy, pasager VIP
Se da un zbor economy
Cand avem un pasager VIP
Apoi putem sa il adaugam dar nu il putem scoate din cadrul unui zbor economy
Si nu putem adauga un pasager VIP la un zbor economy de mai multe ori

Scenariu: Zbor business, pasager obisnuit
Se da un zbor business
Cand avem un pasager obisnuit
Apoi nu il putem adauga sau indeparta din cadrul unui zbor business

Scenariu: Business flight, VIP passenger
Se da un zbor business
Cand avem un pasager VIP
Apoi il putem adauga dar nu il putem scoate din cadrul unui zbor business
Si nu putem adauga un pasager VIP la un zbor business de mai multe ori

Scenariu: Zbor premium, pasager obisnuit
Se da un zbor premium
Cand avem un pasager obisnuit
Apoi nu il putem adauga sau scoate de la un zbor premium

Scenariu: Zbor premium, pasager VIP
Se da un zbor premium
Cand avem un pasager VIP
Apoi il putem adauga sau scoate de la un zbor premium
Si nu putem adauga un pasager VIP la un zbor premium de mai multe ori

Vrei sa inveti mai multe despre aceasta tehnologie? Descopera cursurile noastre.

Catalin Tudose
Java and Web Technologies Expert

Originally published at https://www.luxoft-training.ro.