Behavior Driven Development cu JUnit 5. Partea a sasea

Ultimul articol din cadrul seriei noastre despre Behavior Driven Development cu JUnit 5.

Pentru a rula testele Cucumber, vom avea nevoie de o clasa speciala. Numele clasei poate sa fie orice; noi alegem CucumberTest ca denumire.

[…]
@RunWith(Cucumber.class) #1
@CucumberOptions( #2
plugin = {“pretty”}, #3
features = “classpath:features”) #4
public class CucumberTest {

/**
* This class should be empty, step definitions should be in separate classes.
*/

}

In codul de mai sus:

• Adnotam clasa cu @RunWith(Cucumber.class) #1. Cand o executam la fel ca oricl alt JUnit test class rulam toate functionalitatile gasite in classpath in cadrul aceluiasi pachet. Din moment ce nu exista Cucumber JUnit 5 extension la momentul scrierii acestui text, folosim JUnit 4 runner.
• Adnotarea @CucumberOptions #2 ofera optiunea de plugin #3 care este folosita pentru a specifica diferite optiuni de formatare pentru rapoartele de output. Folosind “pretty”, sursa Gherkin este printata alaturi de culorile aditionale (figure 7). Alte optiuni de plugin includ “html” si “json”, dar “pretty” este indeajuns pentru moment. Si optiunea de features #4 ajuta Cucumber sa localizeze feature file in structura folderului de proiect. Ea cauta acest features folder pe classpath — si tine-ti minte faptul ca folderul src/test/resources este mentinut de Maven pe classpath!

Ruland aceste teste, observam ca am pastrat functionalitatea testului care a existat inainte de a trece la Cucumber.

Fig 7. Rularea unui CucumberTest. Sursa Gherki este „pretty-printed”, testele de succes apar cu verde iar code coverage este 100%.

Mai este un avantaj legat de mutarea la BDD. Daca am compara lungimea clasei pre-Cucumber AirportTest (vezi seria noastra de articole despre TDD), care are 207 de linii de cod, cu clasa PassengersPolicy, care are 157 de linii de cod, codul de test este doar 75% din dimensiunea pre-Cucumber dar are code coverage de 100%. Cum obtinem asa ceva? Ne aducem aminte ca fisierul AirportTest continea 7 clase pe 3 nivele: AirportTest la nivelul de top; EconomyFlightTest si BusinessFlightTest la cel de-al doilea nivel; si, la cel de-al treilea nivel, doua clase RegularPassenger si doua clase VipPassenger. Duplicarea codului ne atrage acum atentia, dar aceasta era solutia cand aveam doar JUnit 5.

Cu ajutorul Cucumber, fiecare pas este implementat imediat. Daca avem acelasi pas in mai mult de un scenariu, vom avea cod duplicat.

Concluzii

In cadrul acestei serii am abordat urmatoarele idei:

• Introducerea BDD, o tehnica de software development care incurajeaza echipele sa livreze software de calitate si incurajeaza cooperarea intre stakeholderi
• Analiza beneficiilor BDD: adresarea nevoilor utilizatorilor, claritate, incurajarea schimbarii, sprijin pentru automatizare, focus pe adaugarea de valoare pentru business si reducerea costurilor
• Analiza provocarilor BDD: necesita un nivel ridicat de anagajament si colaborare, interactiune, comunicare directa si feedback constant
• Mutarea unei aplicatii TDD la BDD cu ajutorul Cucumber prin crearea unei functii separate, generarea unui skeleton in codul de testare, scrierea de teste si implementarea de cod

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