Behavior Driven Development cu JUnit 5. Partea a doua
Behavior Driven Development cu JUnit 5. Partea a doua
Cea de-a doua parte a seriei noastre despre Behavior Driven Development cu JUnit 5.
14 Apr 2021
5604
Other articles
Object-relational Mapping folosind JPA, Hibernate si Spring Data JPA. Persistence cu JPA
Cum sa interogam Kafka Streaming Data?
Procrastinarea. Care sunt avantajele ei?
Object-relational Mapping folosind JPA, Hibernate si Spring Data JPA
Procrastinarea
Cerinte. De ce avem nevoie de ele?
Dezvolta-ti abilitatile cu training-urile noastre
Programarea reactiva Java. Implementari
Testarea software. Intrebari tipice si raspunsuri. Continuare
Testarea software. Intrebari tipice si raspunsuri
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