Am folosit Behaviour Driven Development(test driven developement de generatie 2 e un fel de specification driven development care iti clarifica foarte mult flow-urile) pe flow-uri foarte complexe si am avut mult mai putine bug-uri
Ca principiu gasiti ce inseamna Behaviour Driven Development in urmatorul slide:
Sper sa revin si cu un articol tehnic daca am timp care sa mearga mai in profunzime
La inceput TDD a fost definit de catre Kent Beck ca Red -> Green -> Refactor. Dar acesta este un format foarte simplu, abstract si greu de inteles de fapt. Multi au inteles ca incep sa scriu teste si vad eu ce iese => design emergent. Dar de fapt Kent Beck spune ca incepe sa imparta cazurile de testare inainte de a face Red -> Green -> Refactor in cazuri foarte mici care sa poata fi testate rapid, in minute.
BDD este mult mai mult decat TDD in primul rand pentru ca ne concentram pe comportamente. Dan North, Chris Matts si Liz Keogh au venit cu ideea ca de fapt aceste teste mici de care vorbeste Kent Beck sunt niste comportamente ale System Under Test (SUT). In zona de aplicatii web a inceput sa fie folosit extensiv modelul Outside -> In, adica incepem de la user interface cu teste pana finalizam un feature, cu mici ce valideaza comporamente pe layere (collaboration tests). In alte zone de aplicatii mai curand axate pe algoritmi a continuat sa fie folosit modul de testare bazat pe stare despre care vorbeste Ken Beck (state tests).
In al doilea rand BDD vine cu ideea ca foarte important inainte sa incepe sa lucram este conversatia intre diversele roluri. Daca am “palaria” de programator si vreau sa incep un feature, iau niste specs scrise de Business Analyst (poate sa fie si Produc Owner, Tester, Project Manager, Product Manager, etc de la caz la caz) si vreau sa avem o discutie. Acele specs initiale (adesea scrise in format Gherkin) au sensul de a genera conversatii. Dar mult prea des lumea uita de acest aspect cand incepe sa vorbeasca de BDD si se gandeste doar la teste automate.
In al treilea rand BDD vine cu ideea de Executable Specifications. Toate numele testelor trebuie sa fie scrise (la orice nivel: unit, integrated, integration, acceptance, end-to-end, etc) in limbajul domeniului de business. Aceste nume de teste se compileaza si se transforma intr-un document auto-generat de fiecare data cand testele se ruleaza. Putem astfel sa vedem care modul respecta specificatiile initiale si care nu. Acest tip de feedback este foarte util pentru orice persoana de business; putem sa livram aceste specificatii executabile impreuna cu incrementul de produs, sau putem sa le dam acces permanent sa isi verifice starea actuala a produsului printr-o pagina web de exemplu.
In al patrulea rand in BDD toata lumea implicata in procesul de dezvoltare (programatori, analisti, testeri, manageri, database admins, system admins, etc) cunoaste care este valoarea de business pe care o livreaza prin fiecare feature. In acest mod echipa reuseste sa gaseasca variante eficiente din punct de vedere tehnic pentru a satiface nevoia imediata a clientului si / sau a utilizatorului.
Păcat că demo-ul nu are și un link spre git repository. Deși nu am văzut cum ar arata acest demo, cred că este doar tdd, doar inner circle cu jasmine care este un bdd spec framework.
M-ar interesa un exemplu care sa folosească pentru bdd story cucumber.js si care sa folosească același features files de la backend, iar pentru bdd spec poate jasmine sau altceva.