Domanda

Dopo aver scritto un piccolo articolo su BDD, ho ricevuto domande da persone chiedendo se ci sono casi di uso su larga scala di BDD (e in particolare NBehave).

Quindi la mia domanda va alla comunità: hai un progetto che ha usato BDD con successo? In tal caso, quali vantaggi hai ottenuto e cosa avrebbe potuto essere migliore? Faresti di nuovo BDD? Lo consiglieresti ad altre persone?

È stato utile?

Soluzione

Abbiamo usato un po 'di BDD a livello di codice in diversi scenari (progetti open source e ND).

  1. Raccontare la vista nello scenario MVC, che tipo di input accettare dall'utente ( Convalida dell'interfaccia utente basata su DDD e regole in .NET )

    result = view.GetData(
      CustomerIs.Valid, 
      CustomerIs.From(AddressIs.Valid, AddressIs.In(Country.Russia)));
    
  2. Raccontare il livello di servizio sul comportamento di gestione delle eccezioni ( ActionPolicy viene iniettato nei decoratori):

    var policy = ActionPolicy
      .Handle<WebException>()
      .Retry(3);
    

L'uso di questi approcci ha ridotto enormemente la duplicazione del codice, rendendo la base di codice più stabile e flessibile. Inoltre, ha reso tutto più semplice, grazie all'incapsulamento logico di dettagli complessi.

Altri suggerimenti

Facevo parte di un piccolo team che utilizzava BDD su un sito Web.

Il modo in cui l'abbiamo usato era essenzialmente TDD, ma i test sono semplicemente scritti come comportamenti usando un DSL. Non siamo entrati nel grande design iniziale dei comportamenti, ma ne abbiamo creati un gran numero e li abbiamo usati esattamente come faresti per i test.

Come ci si potrebbe aspettare, ha funzionato molto come TDD, generalmente buono. Definire i test come comportamenti era bello quando interagivo con i clienti e creava un documento abbastanza decente, ma vorrei che i comportamenti fossero scritti in inglese e i test programmati invece di cercare di trovare una lingua intermedia difficile che non si adatta perfettamente a entrambi gli scopi.

Sarebbe ancora BDD, proprio senza questo simpatico trucco di cercare di trasformare la lingua in una lingua delineata da un random_ looking.set of_Punctuation piuttosto_questo semplice.spazi, ma quello era solo il mio atteggiamento scontroso-vecchio programmatore, tutti gli altri lo erano 100% soddisfatto.

Il sito è disponibile e pienamente operativo, quindi lo definirei un successo: Dai un'occhiata

Recentemente ho usato lo stile BDD di GWT in un documento di requisiti di alto livello. Non ho ricevuto alcun feedback sul GWT dal cliente, il mio capo ha detto che gli piaceva perché era molto chiaro e facile da capire. Nota che non ha alcuna conoscenza di BDD di cui io sia a conoscenza. Non ho inserito storie utente in quanto probabilmente sarebbe stata una fata un po 'troppo ariosa per le persone con un tradizionale sfondo a cascata. Forse proverò a inserire le storie degli utenti la prossima volta.

A proposito, questo non era un progetto dell'interfaccia utente a bulbo oculare. Era un progetto di integrazione che sincronizzava i dati da un servizio Web in un database. Quindi dimostra che GWT funziona anche per non "eyeball" Interfacce utente.

Sto usando lo stile Context-Specification su diversi progetti (usando MSpec) con grande successo. Sto ancora cercando di capire i reali vantaggi dello stile Scenario. Più utilizzo lo stile delle specifiche di contesto, più mi piace e più si sentono le mie applicazioni.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top