Quali sono i vantaggi di BDD per uno sviluppatore solista?

Prima di tutto, lascia che aggiunga un po 'di chiarezza. BDD non è esattamente TDD. Un sacco di persone confondono i due perché entrambi iniziano con il concetto di scrivere test prima di codificare. BDD è stato descritto come "migliore TDD" o "facendo TDD giusto", ma non sono sicuro che sia valido. Personalmente, considero BDD come un TDD rifocalizzato.

L'idea è che sei in grado di fare una serie di cose a cui molti altri approcci a volte fanno fatica, e questi sono alcuni dei vantaggi che probabilmente stai cercando:

1. Il tuo codice di prova cattura tutti i tuoi requisiti in una forma leggibile dall'uomo. Non sto solo parlando di nomi di metodi e codice abilmente fattorizzato, ma invece l'uso di un buon framework BDD ti permette di scrivere i tuoi test usando la lingua della funzione o del testo della storia che avresti scritto in un documento dei requisiti. (Guarda come StoryQ per dotNet come esempio).
2. Il tuo codice di test in realtà finisce per testare i tuoi requisiti. Se scrivi il test nella lingua della specifica della tua funzione, finisci per testare direttamente le specifiche.
3. L'output del test viene letto come un report. La maggior parte degli scenari di test unitari si traduce in un gruppo di luci o di flag su schermo per indicare il superamento o il fallimento, ma non si ha idea di dove si sia verificato l'errore effettivo oltre la posizione approssimativa in cui è stato attivato. L'output BDD fornisce informazioni sull'errore indipendentemente dal fatto che si sia verificato l'errore nell'esecuzione del codice o nelle parti di configurazione del test, che mi portano al punto successivo ...
4. Il tuo codice di test diventa altamente dettagliato e ti consente di individuare più facilmente la natura dei guasti nel tuo test / codice.
5. Il feedback continuo dal vivo attraverso i test significa che tendi a lavorare un po 'più efficientemente, specialmente se stai applicando rigorosamente un processo Test Driven. Personalmente, scrivo tutti i miei test prima di iniziare a scrivere qualsiasi codice. È una sorta di design up-front senza essere troppo legato a qualcosa di specifico, e facilmente refactored se cambio idea in seguito.

Per quello che vale, io uso BDD indipendentemente dal fatto che sia nel mio lavoro, o da parte mia progetti a casa. Sto lentamente convertendo gli altri nel mio ambiente di lavoro con questo approccio, perché sono in grado di mostrare i vantaggi in termini di produttività e il piacevole effetto collaterale di avere test più chiari e leggibili, e un codice più pulito e leggibile - anche se quell'ultimo bit non è sottinteso come beneficio BDD, ma solo per mostrarti che personalmente mi sono trovato più inclinato in quella direzione.

Saluti.

Un strong vantaggio che vedo in TDD e BDD è che devi chiarire le tue esigenze. una cosa che vedo spesso con non BDD, non sono chiare o addirittura contraddittorie. Il BDD "ti costringe" a scriverli e quindi a pensarli, prima di scrivere qualsiasi riga di codice. Ho visto il codice non TDD compiere diversi turni, e un sacco di YAGNI, a causa di requisiti mutevoli o poco chiari. puoi evitarlo e proteggerti un po 'di problemi scrivendo prima i requisiti come test / funzionalità eseguibili.

Considero il BDD come un modo per ragionare su un problema dal punto di vista del valore che una caratteristica o simili alla fine forniranno.

La premessa di base di TDD era essenzialmente un pattern o un processo per fare test: scrivere solo un codice di test sufficiente per fallire il test, scrivere solo un codice sufficiente per fare passare quel test, refactoring, repeat. Si è concentrato su come , non perché . In questa luce, trovo il BDD più utile, in quanto costringe le persone a riflettere sul motivo per cui stanno addirittura testando e quale beneficio netto - quale utile comportamento - sarà fornito dal loro codice una volta superati questi test.

Dici di lavorare da solo, ma sembra che tu stia scrivendo il codice per altre persone, quindi deve esserci qualche comunicazione sui requisiti in corso.

Annotare i criteri di accettazione prima di iniziare un lavoro è solo buon senso. Se puoi fare un ulteriore passo avanti e automatizzarlo, allora è grandioso.

Tuttavia, imparare come scrivere i criteri di accettazione ad un livello appropriato per essere di interesse per i tuoi stakeholder richiede abilità e pratica.

BDD è solo test di integrazione. Il fatto che essi possano essere scrivibili da non-sviluppatori è una grande attrazione, ma incidentale se non c'è nessuno tranne gli sviluppatori. Il fatto che siano leggibili da non-dev, in particolare l'output, è un grosso problema, dal momento che finisce con l'essere ridotto a ciò che il sistema può e non può fare, e che tipo di aspettative il sistema ha.

Quindi stai sostanzialmente chiedendo "ho davvero bisogno di testare che tutto il mio sistema funzioni", che si spera che tu conosca la risposta.

Ignorerei BDD come parola d'ordine e andrei avanti con design / codice. Queste metodologie sono così banali che le reinventerai o ti inventerai qualcosa di meglio senza fare uno sforzo consapevole.

Conosciuto anche come programmazione, motherf * cker