Behavior Driven Development cu JUnit 5. Partea a doua

Cea de-a doua parte a seriei noastre despre Behavior Driven Development cu JUnit 5.

De la analiza cerintelor la criterii de acceptare

Pentru compania care ar urma sa foloseasca aplicatia de management al zborurilor, un obiectiv de business pe care l-am putea formula este „cresterea vanzarilor prin imbunatatirea calitatii serviciilor”. Acest obiectiv este unul general insa, dar poate sa fie detaliat prin intermediul cerintelor:

• Oferirea unei aplicatii interactive prin care zborurile pot sa fie alese
• Oferirea unei aplicatii interactive prin care zborurile pot sa fie schimbate
• Oferirea unei aplicatii interactive care sa calculeze cea mai scurta ruta intre orasul de plecare si destinatie

Pentru a face clientul fericit, functionalitatile generate de analiza cerintelor trebuie sa indeplinesca obiectivele clientilor sau sa ofere business value. Ideile initiale trebuie sa fie descrise mai in detaliu. Un mod prin care am putea sa descriem cerintele de mai sus ar fi:

Ca pasager
Vreau sa stiu care sunt zborurile catre o anumita destinatie intr-o anumita perioada de timp
Ca sa pot alege zborul / zborurile care se potriveste / potrivesc nevoilor mele

sau

Ca pasager
Vreau sa pot schimba zborul / zborurile mele initial / initiale cu unul diferit / unele diferite
Ca sa ma pot adapta schimbarilor din programul meu

O functionalitate precum „Vreau sa aleg zborurile care se potrivesc nevoilor mele” s-ar putea sa fie prea greu de implementat — asa ca trebuie impartita in functionalitati mai mici. S-ar putea sa vrei sa obtii si feedback pe parcursul implementarii diferitelor functionalitati. Functionalitatea de care discutam anterior poate sa fie impartita in functionalitati mai mici (stories). Spre exemplu:

Gaseste zborurile directe care se potrivesc nevoilor mele (daca exista)
Gaseste alternativele la zboruri cu escale care se potrivesc nevoilor mele
Gaseste zborurile dus care se potrivesc nevoilor mele
Gaseste zborurile dus-intors care se potrivesc nevoilor mele

In general, se folosesc exemple particulare drept criterii de acceptare. Criteriile de acceptare exprima ce l-ar face pe un stakeholder sa accepte faptul ca aplicatia functioneza conform asteptarilor. In BDD, criteriile de acceptare sunt definite folosind cuvintele Se dau, Cand si Apoi (Given/When/Then):

Se dau (un context)
Cand (are loc o actiune)
Apoi (ne asteptam la un rezultat)

Iata un exemplu concret

Se dau zborurile operate de companie
Cand vreau sa calatoresc de la Bucuresti la Londra miercurea viitoare
Apoi ar trebui sa mi se ofere doua zboruri posibile: 10:35 si 16:20

Beneficii si provocari ale Behavior Driven Development (BDD)

Iata cateva beneficii ale abordarii BDD:

• Adreseaza nevoile utilizatorilor — Utilizatorilor le pasa mai putin de implementare si sunt in principal interesati de functionalitatile aplicatiei. Lucrand in stilul BDD, ne apropiem mai mult de adresarea acestor nevoi.
• Ofera claritate — Scenariile clarifica ce ar trebui sa faca software-ul. Sunt descrise folosind un limbaj simplu care este usor de inteles atat de persoanele tehnice cat si de cele non-tehnice. Orice ambiguitati pot sa fie clarificate analizand scenariul sau adaugand alt scenariu.
• Sprijina schimbarea — Scenariile reprezinta parte din documentatia software-ului: este o documentatie vie, si evolueaza simultan cu aplicatia. Ajuta si la localizarea schimbarilor. Automated acceptance tests impiedica introducerea regresiilor cand sunt introduse schimbari noi.
• Sprijina automatizarea — Scenariile pot sa fie transformate in teste automate, deoarece pasii din scenariu sunt deja definiti.
• Se concentreaza pe adaugarea de business value — BDD previne introducerea de functionalitati care nu sunt utile pentru proiect. De asemenea putem sa prioritizam si functionalitatile.
• Reduce costurile — Prioritizarea functionalitatilor in functie de importanta si evitarea implementarii celor care nu sunt necesare ne ajuta sa nu folosim inutil resurse si sa folosim resursele pe care le avem pentru a face exact lucrurile de care este nevoie

Provocarile BDD tin de faptul ca necesita angajament, colaborare, interactiune, comunicare directa si feedback constant. Acest lucru ar putea sa fie provocator pentru unii oameni, avand in vedere lucrul in echipe distribuite si faptul ca de multe ori clientii si echipa s-ar putea sa lucreze pe fusuri orare diferite.

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.