TSM - BDD, marca Cucumber

Sergiu Indrie - Software Engineer@iQuest

Se pare că un nou framework de testare câștigă popularitate pe internet, în special în zona Java, resuscitând conceptul de BDD. Cucumber este un tool software utilizat pentru rularea testelor automate de acceptanță într-un format lizibil din punct de vedere al businessului.

Conceptul de BDD sau Behavior-Driven Development (Proiectare dirijată de comportament) există de o vreme bună, primele articole și proiecte (JBehave [5] și RSpec [6]) apărând prin 2007. Cum se indică pe site-ul proiectului, Cucumber este o rescriere a celor două framework-uri menționate anterior.

Concepte

BDD

Cea mai importantă idee ce trebuie reținută din acest articol este conceptul de BDD în sine. Behavior-Driven Development nu înseamnă doar alegerea unui framework de teste relevant și scrierea de teste; pentru a reuși să obținem valoare trebuie să înțelegem ideea de bază din spatele acestui proces de dezvoltare software. (Vezi articolele [7] și [8]). Această metodă s-a născut datorită nevoii unei mai bune colaborări între persoanele de business, programatori și tester-i. Astfel dacă dorim să profităm de pe urma BDD, trebuie să pornim cu ideea unui efort comun susținut de toți participanții procesului de dezvoltare.

Un test Cucumber

Un test Cucumber are nevoie de urmatoarele trei elemente :

un fișier feature,
definiții de pași (steps),
cod de business.

Fișierul feature

Un fișier feature este un fișier în format plain, text scris în limbajul Gherkin, un limbaj lizibil din punct de vedere al business-ului care permite descrierea comportamentului aplicației într-un format liber.

Mai jos este un exemplu de fișier feature.
Feature: Refund item

Scenario: Jeff returns a faulty microwave

Given Jeff has boght a microwave for $100

And he has a receipt

When he returns the microwave

Then Jeff should be refunded $100

Fișierul feature este compus din cel puțin un scenariu (scenario; de fapt un test) care la rândul lui este compus din cel puțin un pas (step). Fișierele feature pot utiliza diferite mecanisme de structură cum ar fi descrieri, comentarii, tag-uri, o zonă comună de inițializare și diferite metode de a pune în parametri pașii unui scenariu.

Definițiile pașilor (Step definitions)

După cum am văzut mai sus, un scenariu este compus din mai mulți pași cum ar fi "Jeff has bought a microwave for $100" și "he has a receipt". Toți acești pași sunt abstractizări în text liber ale unui cod de legătură numit glue code. Pentru a putea acoperi primul pas este nevoie de o metodă Java precum cea de mai jos:

@Given("^Jeff has bought a microwave for \\$(\\d+)$")
public void Jeff_has_bought_a_microwave_for_$(int amountOfMoney) {
   business.buyMicrowave(amountOfMoney);
}

Pasul Gherkin este asociat metodei Java cu ajutorul expresiilor regulate. În acest caz, expresia (regex) "^Jeff has bought a microwave for \$(\d+)$" va valida fraza "Jeff has bought a microwave for $100". Observăm faptul că prețul aparatului este extras ca un grup regex. Acesta este mecanismul utilizat de Cucumber pentru a obține valorile variabilelor din fișierul feature scris în format liber.

Fișierul Java ce conține definițiile pașilor se află mai jos:

public class RefundSteps {
   private Business business = new Business();
   @Given("^Jeff has bought a microwave for \\$(\\d+)$")
   public void Jeff_has_bought_a_microwave_for_$(int amountOfMoney) {
       business.buyMicrowave(amountOfMoney);
   }
   @And("^he has a receipt$")
   public void he_has_a_receipt() {
       business.hasReceipt();
   }
   @When("^he returns the microwave$")
   public void he_returns_the_microwave() {
       business.returnMicrowave();
   }
   @Then("^Jeff should be refunded \\$(\\d+)$")
   public void Jeff_should_be_refunded_$(int amountOfMoney) {
       business.refund(amountOfMoney);
   }
}

Fișierele Java cu definițiile pașilor pot conține adnotările @Before și @After cu scop similar celor din framework-ul Junit. Pot folosi un mecanism de raportare (prin injectarea unui obiect de tip Scenario) pentru a personaliza raportul de rezultate ale testelor prin includerea de text și imagine.

Cod Business

În final, codul din definițiile pașilor va apela codul de business al aplicației.

Tool-uri

Din punct de vedere al limbajelor de programare, Cucumber este foarte flexibil, fiind compatibil cu limbajele de programare principale cum ar fi Java, .NET, C++, PHP și altele. Din perspectiva Java, există două artefacte disponibile, unul pentru Java 8 și unul pentru versiunile anterioare. Unele din principalele framework-uri compatibile sunt Spring, Selenium și Ruby on Rails. Cu toate că acest framework de BDD nu este extrem de popular încă, este disponibil în principalele IDE-uri Java de cel puțin un an (Intellij IDEA începând cu versiunea 12; Eclipse începând cu ianuarie 2014). Deținerea funcționalităților precum syntax highlighting și autocomplete la nivel de pași, navigarea în cadrul pașilor, căutarea utilizării pașilor, generarea codului schelet pentru noii pași și rularea de teste creează condiții pentru o scriere facilă de teste Cucumber. Integrarea cu Maven este simplă și intuitivă pentru uzul de bază - presupunând plasarea tuturor artefactelor în aceleași pachete și utilizarea unei clase de test adnotată pentru a fi rulată de Cucumber- , însă scenariile mai avansate ar putea beneficia de un plugin specializat, pur Java de Maven (vezi [12]). De asemenea, e posibil ca structura ierarhică de fișiere feature să fie la un nivel mai înalt de abstractizare decât pachetele Java și deci diferită de structura pachetelor de definire a pașilor.

O clasă de test Java care va rula toate fișierele feature din același pachet:

package com.tsm.bdd;
import cucumber.api.junit.Cucumber;
import org.junit.runner.RunWith;
@RunWith(Cucumber.class)
public class RefundTest {
}

Abordările pentru a rula testele Cucumber cu un setup mai complex utilizând Maven sunt:

utilizarea exec-maven-plugin pentru a apela clasa main din jar-ul Cucumber și a pasa argumentele necesare;
selectarea suitei de teste folosind clasa de test necesară (în pachetul necesar) și configurarea opțiunilor Cucumber ca o proprietate sistem și pasarea acestora către maven-surefire-plugin.

Folosind exec-maven-plugin :

<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>exec-maven-plugin</artifactId>
   <version>${exec-maven-plugin.version}</version>
   <executions>
       <execution>
           <phase>test</phase>
           <goals>
               <goal>java</goal>
           </goals>
           <configuration>
               <classpathScope>test</classpathScope>
               <mainClass>cucumber.api.cli.Main</mainClass>
               <arguments>
                   <argument>--format</argument>
                   <argument>${format}</argument>
                   <argument>--strict</argument>
                   <argument>--glue</argument>
                   <argument>target/test-classes</argument>
                   <argument>target/test-classes/.</argument>
                   <argument>--tags</argument>
                   <argument>~@ignore</argument>
                   <argument>--tags</argument>
                   <argument>${tagArg}</argument>
               </arguments>
           </configuration>
       </execution>
   </executions>
</plugin>

Folosind maven-surefire-plugin :

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <version>2.18.1</version>
   <configuration>
       <test>${java.test}</test>
       <systemPropertyVariables>
           <cucumber.options>
               --monochrome
               --strict
               --plugin pretty
               --plugin html:..\logs\report\html-report-java
               --plugin json:..\logs\report\json-reports\${json.name.java}
               --plugin junit:..\logs\report\junit-java.xml
               --tags ~@skip
           </cucumber.options>
       </systemPropertyVariables>
   </configuration>
</plugin>

De asemenea, trebuie menționat faptul că există câteva plugin-uri (de Jenkins) care simplifică integrarea testelor Cucumber în mediul Jenkins.

Observații

Dintr-o perspectivă BDD, Cucumber nu are o contribuție majoră, în special când e comparat cu JBehave (vezi [11]) care are o abordare foarte asemănătoare.

În ansamblu, Cucumber pare să își îndeplinească misiunea de a oferi un mediu simplu de colaborare între diferitele părți implicate folosind limbajul Gherkin, și de a spori lizibilitatea testelor scrise de programatori. Însă, din punct de vedere al programatorului, framework-ul nu dă impresia de maturitate având mici lipsuri la descrierea și scrierea testelor (vezi [9]), documentație publică nefinalizată (vezi [10]) și complexitate în configurarea unui mod unificat de a rula testele (Maven vs IDE).