miniatura | Trevor Parscal programant a les oficines de la Fundació Wikimedia. El desenvolupament basat en el comportament (BDD) implica anomenar proves de programari utilitzant llenguatge de domini per descriure el comportament del codi.

El BDD implica l'ús d'un llenguatge específic de domini (DSL) utilitzant construccions de llenguatge natural (per exemple, frases semblants a l'anglès) que poden expressar el comportament i els resultats esperats.

Els defensors afirmen que fomenta la col·laboració entre desenvolupadors, experts en garantia de qualitat i representants de clients en un projecte de programari. Anima els equips a utilitzar la conversa i exemples concrets per formalitzar una comprensió compartida de com s'hauria de comportar l'aplicació. El BDD es considera una pràctica eficaç, especialment quan lespai del problema és complex.

El BDD es considera un refinament del desenvolupament basat en proves (TDD). El BDD combina les tècniques del TDD amb idees del disseny basat en dominis i l'anàlisi i el disseny orientats a objectes per proporcionar als equips de desenvolupament i gestió de programari eines compartides i un procés compartit per col·laborar en el desenvolupament de programari.

En un nivell general, el BDD és una idea sobre com el desenvolupament de programari s'ha de gestionar tant pels interessos comercials com pels coneixements tècnics. La seva pràctica implica l'ús d'eines especialitzades. Algunes eines específiques per a BDD es poden utilitzar per a TDD. Les eines automatitzen el llenguatge omnipresent.

Visió general BDD és un procés pel qual les instruccions estructurades en llenguatge natural DSL es converteixen en proves executables. El resultat són proves que es llegeixen com a criteris d'acceptació per a una funció determinada.

Per tant, BDD és una extensió de TDD.

El BDD se centra en:

Per on començar en el procés Què provar i què no provar Quant provar de cop Com s'han de dir les proves Com entendre per què falla una prova

En essència, BDD tracta de repensar l'enfocament de les proves automatitzades (incloses les proves unitàries i les proves d'acceptació) per tal d'evitar problemes que sorgeixen naturalment. Per exemple, BDD suggereix que els noms de les proves unitàries siguin frases senceres que comencin amb un verb condicional ("should" en anglès, per exemple) i s'haurien d'escriure en ordre de valor empresarial. Les proves d'acceptació s'haurien d'escriure utilitzant el marc àgil estàndard d'una història d'usuari: "Com a [rol/actor/part interessada], vull una [característica/capacitat] que produeixi un [benefici]". Els criteris d'acceptació s'haurien d'escriure en termes d'escenaris i implementar-los en classes: Donat el [context inicial], quan [es produeix l'esdeveniment], aleshores [assegurar alguns resultats].

A partir d'aquest punt, molta gent va desenvolupar marcs de treball BDD durant anys, i finalment els va emmarcar en termes d'un marc de comunicació i col·laboració per a desenvolupadors, control de qualitat i participants no tècnics o empresarials en un projecte de programari.

Principis El BDD suggereix que les proves de programari s'haurien de denominar en termes de comportament desitjat. Prenent del desenvolupament de programari àgil, el "comportament desitjat" en aquest cas consisteix en els requisits establerts per l'empresa — és a dir, el comportament desitjat que té valor empresarial per a qualsevol entitat que hagi encarregat la unitat de programari en construcció. Dins de la pràctica del BDD, això es coneix com a BDD com una activitat "de fora cap a dins".

El TDD no diferencia les proves en termes de requisits de programari d'alt nivell, detalls tècnics de baix nivell ni res entremig. Per tant, una manera de veure el BDD és que és una evolució del TDD que fa eleccions més específiques.

Especificacions de comportament Un altre suggeriment de BDD es relaciona amb com s'hauria d'especificar el comportament desitjat. BDD suggereix utilitzar un format semiformal per a l'especificació del comportament que es pren prestat de les especificacions d'històries d'usuari del camp de l'anàlisi i el disseny orientats a objectes. L'aspecte d'escenari d'aquest format es pot considerar com una aplicació de la lògica de Hoare a l'especificació del comportament del programari utilitzant el llenguatge específic del domini.

BDD suggereix que els analistes de negoci i els desenvolupadors de programari col·laborin en aquesta àrea i especifiquin el comportament en termes d'històries d'usuari, que estan documentades explícitament. Cada història d'usuari hauria de seguir, fins a cert punt, l'estructura:

Títol Un títol explícit.

Narrativa Una breu secció introductòria amb la següent estructura: Com a: la persona o el rol que es beneficiarà de la funció; Vull: la funció; de manera que: el benefici o valor de la característica.

Criteris d'acceptació Una descripció de cada escenari específic de la narració amb la següent estructura: Donat: el context inicial al principi de l'escenari, en una o més clàusules; Quan: l'esdeveniment que desencadena l'escenari; Aleshores: el resultat esperat, en una o més clàusules.

BDD no requereix com es formata aquesta informació, però sí que suggereix que un equip hauria de decidir un format relativament simple i estandarditzat amb els elements anteriors. També suggereix que els escenaris s'haurien de formular de manera declarativa en lloc d'imperativa, en el llenguatge empresarial, sense cap referència als elements de la interfície d'usuari a través dels quals es produeixen les interaccions. Aquest format es coneix a Cucumber com a llenguatge Gherkin.

L'especificació com a llenguatge omnipresent El BDD pren prestat el concepte de llenguatge ubic'' del disseny basat en dominis. Un llenguatge ubic és un llenguatge (semi)formal que comparteixen tots els membres d'un equip de desenvolupament de programari — tant els desenvolupadors de programari com el personal no tècnic. El llenguatge en qüestió és utilitzat i desenvolupat per tots els membres de l'equip com a mitjà comú per discutir el domini del programari en qüestió. D'aquesta manera, el BDD esdevé un vehicle de comunicació entre tots els diferents rols d'un projecte de programari.

Un risc comú en el desenvolupament de programari inclou les fallades de comunicació entre desenvolupadors i parts interessades del negoci. BDD utilitza l'especificació del comportament desitjat com a llenguatge omnipresent per als membres de l'equip del projecte. Aquesta és la raó per la qual BDD insisteix en un llenguatge semiformal per a l'especificació del comportament: certa formalitat és un requisit per ser un llenguatge omnipresent. A més, tenir un llenguatge tan omnipresent crea un model de domini d'especificacions, de manera que les especificacions es poden raonar formalment. Aquest model també és la base de les diferents eines de programari de suport de BDD que estan disponibles.

L'exemple anterior estableix una història d'usuari per a un sistema de programari en desenvolupament. Aquesta història d'usuari identifica una part interessada, un efecte empresarial i un valor empresarial. També descriu diversos escenaris, cadascun amb una precondició, un desencadenant i un resultat esperat. Cadascuna d'aquestes parts s'identifica exactament per la part més formal del llenguatge (el terme *Given* es podria considerar una paraula clau, per exemple) i, per tant, pot ser processada d'alguna manera per una eina que entengui les parts formals del llenguatge omnipresent.

La majoria d'aplicacions BDD utilitzen DSL basats en text i enfocaments d'especificació. Tanmateix, la modelització gràfica d'escenaris d'integració també s'ha aplicat amb èxit a la pràctica, per exemple, amb finalitats de prova.

Eines especialitzades De la mateixa manera que el TDD, el BDD pot implicar l'ús d'eines especialitzades.

El BDD no només requereix codi de prova com el TDD, sinó també un document que descrigui el comportament en un llenguatge més llegible per als humans. Això requereix un procés de dos passos per executar les proves, llegir i analitzar les descripcions, i llegir el codi de prova i trobar la implementació de prova corresponent per executar. Aquest procés fa que el BDD sigui més laboriós per als desenvolupadors. Els defensors suggereixen que, a causa de la seva naturalesa llegible per als humans, el valor d'aquests documents s'estén a un públic relativament no tècnic i, per tant, pot servir com a mitjà de comunicació per descriure els requisits ("característiques").

Principis d'utillatge En principi, una eina de suport BDD és un marc de proves per a programari, de manera molt semblant a les eines que donen suport a TDD. Tanmateix, mentre que les eines TDD solen tenir un format força lliure pel que fa al que es permet per especificar proves, les eines BDD estan vinculades a la definició del llenguatge omnipresent.

El llenguatge omnipresent permet als analistes de negoci documentar els requisits de comportament d'una manera que també els desenvolupadors entendran. El principi de les eines de suport BDD és fer que aquests mateixos documents de requisits siguin directament executables com una col·lecció de proves. Si això no es pot aconseguir per motius relacionats amb l'eina tècnica que permet l'execució de les especificacions, cal modificar l'estil d'escriptura dels requisits de comportament o bé canviar l'eina. La implementació exacta dels requisits de comportament varia segons l'eina, però la pràctica àgil ha donat lloc al següent procés general:

L'eina llegeix un document d'especificacions. L'eina entén directament i completament les parts formals del llenguatge omnipresent (com ara la paraula clau Given''' a l'exemple anterior). A partir d'això, l'eina divideix cada escenari en clàusules significatives. Cada clàusula individual d'un escenari es transforma en una mena de paràmetre per a una prova de la història d'usuari. Aquesta part requereix un treball específic del projecte per part dels desenvolupadors de programari. El marc de treball executa la prova per a cada escenari, amb els paràmetres d'aquest escenari.

Referències

Categoria:Programari Categoria:Desenvolupament de programari