Șeful tău nu va aprecia TDD: Încearcă acest exemplu de dezvoltare bazată pe comportament

Testare. Adesea este lăsat în ultimul minut, apoi tăiat pentru că nu ai timp, ai depășit bugetul sau orice altceva.

Conducerea se întreabă de ce dezvoltatorii nu pot „să facă bine de prima dată”, iar dezvoltatorii (în special pe sistemele mari) pot fi luați cu nerăbdare atunci când diferite părți interesate descriu diferite părți ale sistemului, cum ar fi povestea orbilor care descriu un elefant.

Este inevitabil, totuși, ca primul pas în fiecare proiect să fie o discuție despre comportamentele software-ului sau caracteristicii care urmează să fie construite. Un client sau un om de afaceri se apropie de cineva din echipa de dezvoltare și îi explică ceea ce își dorește.

Uneori, aceste interacțiuni vin sub forma unei povești de utilizator Agile. Uneori vin sub formă de documente de design, ca în articolul lui Chris Fox pe blog de anul trecut. Ele pot veni, de asemenea, sub formă de diagrame de flux sau machete în Keynote, sau chiar apeluri telefonice grăbite.

Numai din aceste comunicări, un dezvoltator este responsabil pentru construirea unui sistem care „funcționează”. Acest lucru este deosebit de dificil pentru freelanceri care lucrează în afara sistemului mai mare.

De ce se întrerupe testarea?

Există un decalaj evident aici: dacă proprietarul afacerii și-a imaginat comportamentele sistemului de la început, de ce este testarea faptului că aceste comportamente funcționează adesea pasul care este tăiat?

Răspunsul poate fi orbitor de simplu: testele nu sunt adesea văzute ca capital social ; ele nu sunt considerate ca având valoare pentru proiect, deoarece „sunt doar pentru ingineri” sau, în mod similar, oferă valoare unui singur departament sau grup de oameni.

Cum testăm acest capital comun, această listă de comportamente ale sistemului? Prin adoptarea nu numai a dezvoltării bazate pe teste (TDD), ci și a dezvoltării bazate pe comportament (BDD).

Ce este BDD?

Dezvoltarea bazată pe comportament ar trebui să se concentreze pe comportamentele de afaceri pe care codul dvs. le implementează: „de ce” din spatele codului . Suportă un flux de lucru centrat pe echipă (în special interfuncțional).

Am văzut că BDD agil funcționează foarte bine atunci când un dezvoltator și fie proprietarul produsului Agile, fie un analist de afaceri stau împreună și scriu specificații în așteptare (care vor fi completate mai târziu de către dezvoltator) într-un editor de text simplu:

1. Persoana de afaceri specifică comportamentele pe care dorește să le vadă în sistem.
2. Dezvoltatorul pune întrebări pe baza înțelegerii sistemului, notând și comportamentele suplimentare necesare din perspectiva dezvoltării.

În mod ideal, ambele părți se pot referi la lista de comportamente curente ale sistemului pentru a vedea dacă această nouă caracteristică va distruge funcțiile existente.

Am descoperit că acest act simplu îmi oferă suficiente constrângeri pe care pot să mă gândesc ca un dezvoltator: „dat fiind că trebuie să implementez aceste teste, cum mă constrânge pe mine/pe toată lumea în specificațiile pe care le pot implementa în cod”? Deoarece sunt în așteptarea specificațiilor, sunt rapid și ușor de scris în plină colaborare.

Această abordare de colaborare îmi permite să mă concentrez pe ceea ce oferă caracteristica pentru utilizatorul final și, având o persoană de afaceri chiar acolo, mă constrânge să vorbesc despre comportament, nu despre implementare. Acest lucru evidențiază diferențele dintre BDD și TDD.

Să vedem un exemplu de dezvoltare determinată de comportament

Scenariul: Sunteți dezvoltator într-o echipă responsabilă de sistemul de contabilitate al companiei, implementat în Rails. Într-o zi, un om de afaceri vă cere să implementați un sistem de memento pentru a reaminti clienților facturile în așteptare. Pentru că practicați BDD conform acestui tutorial; (versus TDD), te așezi cu acel om de afaceri și începi să definești comportamente.

Deschideți editorul de text și începeți să creați specificații în așteptare pentru comportamentele dorite de utilizatorul de afaceri:

 it "adds a reminder date when an invoice is created" it "sends an email to the invoice's account's primary contact after the reminder date has passed" it "marks that the user has read the email in the invoice"

Accentul pe comportament în timpul dezvoltării face ca testul să fie util pentru verificarea faptului că construiți funcția potrivită, nu doar că codul dvs. este corect. Rețineți că formularea este în limbajul de afaceri, nu în limbajul intern de implementare a sistemului. Nu vezi sau nu-ți pasă că o factură belongs_to unui cont, pentru că nimănui din afara echipei de dezvoltare nu-i pasă de asta.

Unii dezvoltatori preferă să scrie cazuri de testare pe loc, apelând metode în sistem, creând așteptări, așa:

 it "adds a reminder date when an invoice is created" do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

Suita de testare va eșua deoarece încă nu am scris codul pentru a seta reminder_date .

În raport cu specificațiile eșuate

Înțeleg dezvoltatorii care scriu specificații eșuate, dar cu omul de afaceri lângă mine, acest lucru nu a funcționat niciodată pentru mine. Persoana de afaceri greșită fie va fi distrasă de detalii, fie va lua aceste noi cunoștințe și va încerca să microgestioneze lucruri despre care dezvoltatorul știe mai multe (design corect al bazei de date, reutilizarea codului).

Din experiența mea, scrierea mai mult de o privire de ansamblu pe o linie a unui anumit comportament va plictisi persoana de afaceri. Ei îl vor vedea ca pe o utilizare proastă a timpului lor sau vor deveni nerăbdători să descrie următorul comportament în timp ce îl vor gândi.

Cum diferă BDD de TDD?

Să privim asta într-un mod diferit, cu o abordare de dezvoltare bazată pe teste și să scriem testele în așteptare:

 it "after_create an Invoice sets a reminder date to be creation + 20 business days" it "Account#primary_payment_contact returns the current payment contact or the client project manager" it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"

Aceste teste sunt utile, dar numai pentru un grup de oameni: inginerii. BDD este util pentru comunicarea cu fiecare membru al unei echipe de produse interfuncționale.

Cu siguranță puteți face o dezvoltare în primul rând în timp ce aveți o mentalitate BDD prin utilizarea comportamentelor în așteptare. Mai întâi, scrieți testul; apoi rulează-l (roșu); apoi faceți-l să funcționeze (verde); apoi faceți-l corect (refactorizați).

S-a depus multă muncă în comunitatea BDD pentru ca verificările afirmațiilor din interiorul testului să citească ca în limba engleză. Iată un test RSpec stereotip:

 a = 42 a.should == 42

Acest format face lucrurile mai ușor de citit mai târziu. Dar amintiți-vă că nu este ceea ce facem aici - ideea este să reducem comportamentele cât mai repede posibil - și să punem în aplicare principiul „un comportament testat per specificație”. În mod ideal, titlul specificației în așteptare ar trebui să vă spună ce testați.

BDD nu este despre modalități elegante de a vă valida rezultatele; este vorba despre împărtășirea comportamentelor așteptate între toți membrii echipei.

Dezvoltarea bazată pe comportament se referă la colaborare și comunicare

Să ne întoarcem în scenariul nostru: lucrul la sistemul de contabilitate al companiei.

Parcurgeți funcționalitatea articolului împreună cu persoana de afaceri, cu dvs. analizând sistemul prin elementele sale interne (cum se potrivesc obiectele în interior), iar ei analizând sistemul din exterior.

Te gândești la unele condiții și îl întrebi pe analistul de afaceri ce se întâmplă în următoarele scenarii:

 * What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

Și primești răspunsuri . Este important ca omul de afaceri să înțeleagă că nu încercați să faceți găuri în ideea lor de companie sau să fiți prea pedant.

În acest fel, Behavior-Driven Development este un instrument pentru a ajuta colaborarea și a începe o conversație între cele două departamente. Este, de asemenea, o modalitate de a clarifica domeniul de aplicare al unei caracteristici dorite și de a obține estimări mai bune de la echipa de dezvoltare. Poate îți dai seama că nu există nicio modalitate de a calcula 10 zile lucrătoare dintr-un anumit moment în timp; aceasta este o caracteristică suplimentară, separată, pe care va trebui să o implementați.

Dezvoltatorii vor avea considerații pentru dezvoltatori („Ce vrei să spui exact când spui „zi”?”), în timp ce oamenii de afaceri vor avea propriile considerații („Vă rugăm să nu folosiți termenul de întârziere aici, asta înseamnă ceva diferit”). Dacă un grup sau altul pleacă și încearcă să scrie ele însele aceste teste de comportament logic de afaceri (promisiunea Castravetelor) elimină contribuția valoroasă a fiecărei părți.

Este, de asemenea, un bun substitut pentru atunci când Clientul Agil nu mai este fizic în cameră: să-și aibă dorințele pe hârtie, amestecate cu analiza dezvoltatorului (și traducerea) a ceea ce construiești.

Documente de proiectare

O postare anterioară pe blogul Toptal, Chris Fox, vorbește despre documentele de proiectare, mai ales la începutul unui proiect. Înțelegerea și extragerea comportamentelor de afaceri se micșorează de la proiectele în care sistemul este oarecum cunoscut, la cele care necesită decenii de ani-programator pentru a realiza și au sute sau mii de specificații comportamentale.

Articolul lui Chris menționează și comportamentele pe ecran ale elementelor, iar acesta este un domeniu în care sunt constant în dezacord cu designerii: „Cum arată acest buton când este slab” sau „Cum arată acest lucru pe ecranele 11”, pentru că această pagină este în mod evident concepută pentru ecrane de 24 inchi?” Acest dus și înapoi cu persoana de afaceri poate găsi lacune în elementele grafice ale unui proiect sau aspectul unei pagini.

În echipele multifuncționale foarte mari, există mulți membri ai echipei cu propriile preocupări: designeri, dezvoltatori, potențial cineva din operațiuni, administratorul bazei de date — poate oameni QA (da, există un loc pentru toată lumea în TDD și BDD!), fiecare cu propriile lor preocupări și întrebări. BDD poate conduce această colaborare mai mult decât o face dezvoltarea bazată pe teste. De la „ce se întâmplă când datele sunt prea mari pentru acest tabel?” la „Hmmm, asta va fi o interogare costisitoare, vom dori să o memorăm în cache” la „Stai, dacă utilizatorul va vedea toate acele informații confidențiale?”, poate fi mai mult în joc decât un dezvoltator și un analist de afaceri cu întrebări despre această nouă caracteristică

Dezvoltarea bazată pe comportament se referă la artefacte partajate

Ce este un artefact comun?

Îmi place să mă gândesc la „artefactele” din ingineria software ca la lucruri potențial fizice care descriu proiectul sau echipa de proiect și care pot fi găsite la șase luni mai târziu. Artefactele bune explică de ce lucrurile sunt așa cum sunt.

Conversațiile pe hol nu sunt artefacte. Nici desenele cu tablă albă. Desene cu tablă albă care se transformă în documente mari de clasă lungă sau în documente de proiectare - acestea sunt artefacte. Minutele de la întâlniri sunt și ele artefacte.

Un artefact este un cod sursă salvat într-un depozit sau într-un spațiu partajat și bilete în sistemul de bilete sau note pe Wiki intern sau chiar jurnalele de chat persistente.

Artefactele partajate sunt, în opinia mea, cele mai bune artefacte . Ele arată nu doar de ce ceva este așa cum este, ci și de ce există în aplicație.

Cum le folosești în BDD?

Comportamentele ar trebui să fie un artefact de echipă partajat - testele nu ar trebui să fie doar o muncă ocupată pentru programatori! Deși cel mai bine este să aveți un sistem în care întreaga echipă să poată vizualiza cu ușurință specificațiile curente (poate că sistemul de implementare extrage și salvează și lista de comportamente într-o zonă privată a site-ului sau într-un wiki), ați putea face acest lucru manual la fiecare sprint.

Numele jocului este „ajutați dezvoltatorii să creeze specificațiile de care avem nevoie pentru a oferi mai rapid valoarea afacerii, pentru a colabora interdepartamental și pentru a face estimări mai bune”.

Această înțelegere la nivel de companie a ceea ce face sistemul este și o formă de capital. Este „de ce” pentru „cum” al codului.

Concluzie

Cum rezolvăm problema livrării de software cu erori clienților? Asigurându-vă că testarea nu este văzută ca ceva „la care le pasă doar dezvoltatorilor”.

Descrierea și înțelegerea nevoilor unui sistem are o mulțime de beneficii dincolo de corectitudinea codului: stabilirea unui dialog inter-departamental și asigurarea faptului că toate preocupările părților interesate sunt îndeplinite (și nu doar părților interesate cu titluri de lux). Utilizarea dezvoltării bazate pe comportament pentru a înțelege aceste nevoi de la început și testarea comportamentelor externe de afaceri la care ține întreaga echipă – aceasta este o modalitate excelentă de a asigura un proiect de calitate.