BDD smjernice i najbolje prakse

BDD (Behaviour Driven Development) je metodologija za kontinuirani razvoj softvera na primjeru komunikacija između programera, QA-a i BA-a. U ovom članku raspravljamo o nekim najboljim praksama BDD-a kako bismo dobili najviše koristi.

Više od bilo čega drugog, primarna svrha BDD metodologije je potaknuti komunikaciju među dionicima projekta kako bi svi članovi tima (tj. Zajedničko razumijevanje) prije početka razvojnog rada pravilno razumjeli kontekst svake značajke. To pomaže u identificiranju ključnih scenarija za svaku priču, a također uklanja i nejasnoće iz zahtjeva.

U BDD-u se primjeri nazivaju scenariji. Scenariji su strukturirani oko Kontekst-Akcija-Ishod uzorak i napisani su u posebnom formatu koji se naziva Kornišon .

Scenariji su način objašnjavanja (jednostavnim engleskim jezikom) kako bi se određena značajka trebala ponašati u različitim situacijama ili s različitim ulaznim parametrima.

Budući da je Gherkin strukturni, on služi i kao specifikacija i kao ulaz u automatizirane testove, pa otuda i naziv 'Izvršne specifikacije'.

Što je datoteka značajke i što ona sadrži

Datoteke značajki su tekstualne datoteke s .obilježje proširenje, koje može otvoriti bilo koji uređivač teksta, kao i pročitati ga bilo koji alat koji je svjestan BDD-a, poput Krastavca, JBehavea ili Behata.



Datoteke značajki trebaju započeti s kontekstom značajke (što je u osnovi priča), nakon čega slijedi barem jedan scenarij u sljedećem formatu

Značajka: Neki kratak, ali opisan tekst željenog

Da bi se ostvarila imenovana poslovna vrijednost
Kao eksplicitni akter sustava
Želim postići neki blagotvoran ishod koji unapređuje cilj

Scenarij: Neka odrediva poslovna situacija

S obzirom na neki preduvjet
I još neki preduvjet
Kad neka glumčeva akcija
I još neka akcija
I još jedna akcija
Tada se postiže neki provjerljivi ishod
A događa se i nešto drugo što možemo provjeriti

Scenariji u datotekama značajki trebaju se usredotočiti na 'što', a ne na 'kako'. Scenariji bi trebali biti sažeti i precizni, tako da čitatelj može brzo shvatiti namjeru testa, a da ne mora pročitati puno nevažnih koraka.

Zašto bismo trebali pisati značajke

Kao što je spomenuto prije, primarni cilj BDD metodologije je potaknuti komunikaciju među timom za dostavu. Cilj datoteka značajki je dokumentirati scenarije o kojima se razgovaralo kako bi se pokazalo koliki je rad uključen u isporuku značajke. Datoteke značajki ujedno su i pokretači automatskih testova. Datoteke značajki također služe kao definicija gotovog (DoD), što znači da kad svi scenariji budu uspješno implementirani i testirani, možemo priču označiti kao gotovu.

Tko bi trebao pisati značajke

Zapravo nije važno tko zapravo piše / upisuje datoteke značajki, to može biti bilo koji član tima za isporuku, međutim, sadržaj (scenariji) o kojima raspravlja trio Dev-QA-BA su bitni dio značajke datoteke. Ključno je stjecanje zajedničkog zajedničkog razumijevanja značajke.

Kada treba pisati datoteke sa značajkama

Datoteke značajki trebale bi biti napisane tijekom sesija dotjerivanja priča, gdje se raspravlja o detaljima svake priče. Datoteke značajki koje sadrže scenarije trebaju se napisati prije početka razvoja kako bi programeri, kao i QA, imali jasno razumijevanje namjere priče. Trebalo bi postojati zajedničko razumijevanje priče. Scenariji služe kao zahtjevi za razvoj.

Gdje se trebaju čuvati datoteke sa značajkama

Trebao bi postojati jedan izvor istine koji služi i kao specifikacija i kao automatizirano izvršavanje, stoga ga treba čuvati negdje gdje svaki član tima ima lak pristup.

Imajući to u vidu, jer su datoteke značajki pokretači automatiziranih testova, idealno bi ih bilo čuvati u sustavu za kontrolu izvora (GitHub), tako da se svako ažuriranje datoteka značajki odmah odražava na testovima.

Za netehničke članove koji nemaju iskustva s Gitom, uvijek možemo izvršiti suho pokretanje datoteka značajki koje će zatim prikazati popis svih postojećih scenarija bez stvarnog vježbanja datoteka značajki.

Kako bismo trebali pisati značajke

Općenito postoje dva načina pisanja datoteka značajki - imperativni i deklarativni

Imperativ stil pisanja datoteke značajki vrlo je opširan, sadrži detalje na niskoj razini i previše informacija.

Pros: osoba koja čita datoteku značajke može slijediti korak po korak

Protiv: Zbog previše detalja čitatelj može izgubiti poantu priče i testova. Datoteka značajke postaje prevelika, teška za održavanje i vjerojatno neće uspjeti zbog ažuriranja korisničkog sučelja.

Deklarativno stil pisanja datoteke s značajkama je sažet i precizan, sadrži samo relevantne informacije o priči.

Pros: Deklarativni stil je čitljiviji jer sadrži manje koraka u scenariju. Čitač može lako razumjeti opseg testa i brzo prepoznati nedostaju li neki ključni elementi.