Behavior Driven Development cu JUnit 5. Prima parte

In aceasta serie de articole, vom discuta despre cum putem sa dezvoltam aplicatii sigure si flexibile folosind behavior-driven development (BDD). BDD este un proces de software development care incepe cu cerintele si obiectivele de business si le transforma in functionalitati.

Abstract: In aceasta serie de articole, vom discuta despre cum putem sa dezvoltam aplicatii sigure si flexibile folosind behavior-driven development (BDD). BDD este un proces de software development care incepe cu cerintele si obiectivele de business si le transforma in functionalitati. BDD incurajeaza echipele sa interactioneze, sa foloseasca exemple concrete pentru a comunica modul in care aplicatia ar trebui sa se comporte si sa livreze solutii software care sa poata sa fie folosite, incurajand cooperarea intre diferitele parti interesate din proiect. Test Driven Development (TDD) ne ajuta sa dezvoltam solutii software care functioneaza; BDD ne ajuta sa dezvoltam solutii software care aduc valoare in business. Folosind BDD, putem sa identificam ce functionalitati sunt cu adevarat necesare pentru organizatie si sa ne concentram pe a le implementa.

Provocari legate de comunicare la nivel de proiect

Comunicarea intre persoanele implicate in acelasi proiect poate sa genereze probleme si neintelegeri. De obicei fluxul functioneaza asa:

1. Clientul comunica catre analistul de business felul in care el intelege modul in care o functionalitate ar trebui sa functioneze.
2. Analistul de business construieste cerintele pentru programator, descriind modul in care software-ul trebuie sa functioneze.
3. Dezvoltatorul creaza codul pe baza cerintelor si scrie unit tests pentru a implementa noua functionalitate.
4. Software testerul creaza test cases pe baza cerintelor si le foloseste pentru a verifica modul in care functioneaza noua functionalitate.

Dar este posibil ca informatia sa nu fie inteleasa cum trebuie sau sa fie modificata ori ignorata — si astfel noua functionalitate s-ar putea sa nu faca exact ceea ce se astepta de la ea. Vom analiza modul in care functioneaza lucrurile atunci cand o noua functionalitate este introdusa.

Introducerea unei noi functionalitati

Analistul de business discuta cu clientul pentru a decide ce functionalitati software ar putea sa adreseze obiectivele de business. Aceste functionalitati sunt cerinte generale de genul „Sa ii permita calatorului sa aleaga cea mai ieftina cale de a ajunge la destinatie”.

Aceste functionalitati trebuie traduse in stories. Stories de genul „Gasirea rutei intre sursa si destinatie cu numarul cel mai mic de schimbari de zbor” sau „Gasirea celei mai rapide rute intre sursa si destinatie.”

Stories sunt definite prin exemple concrete. Aceste exemple devin criterii de acceptare pentru story. Criteriile de acceptare sunt exprimate in BDD prin cuvintele cheie Se dau, Cand si Apoi.

Ca exemplu putem prezenta urmatorul criteriu de acceptare:
Se dau zborurile operate de compania X
Cand vreau sa gasesc cea mai rapida ruta intre Bucuresti si New York pe 15 Mai 2021…
Apoi mi se v-a oferi ruta Bucuresti-Frankfurt-New York, cu o durata de zbor de …

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.