Sono un po 'confuso riguardo a BDD. Al momento sto facendo TDD.
La mia domanda è se il BDD è complementare al TDD o è una cosa completamente nuova e il mio team dovrebbe fare sia TDD che BDD? O è sufficiente fare solo uno o l'altro?
Per definizione , BDD è basato su TDD ed è un perfezionamento / estensione / specializzazione di quest'ultimo.
is it enough to do just one or the other?
Secondo quanto sopra, non puoi fare BDD senza TDD.
In generale, non esiste una risposta valida per tutti: fare ciò che si adatta meglio alla tua squadra e al tuo progetto. Sentiti libero di sperimentare nuove idee, scegliere ciò che funziona e rilasciare o cambiare ciò che non lo fa.
Inoltre, questa non è una domanda tutto o niente: puoi fare TDD migliorato con idee specifiche da BDD che ritieni siano una valida aggiunta al tuo processo. Ad esempio, ho adattato la convenzione di denominazione "dovrebbe" dei test unitari nella mia pratica perché trovo che rende i miei test unitari più leggibili ed espressivi.
Questa discussione è stata molto attiva negli ultimi anni nella comunità di sviluppo software. Per me almeno BDD ha causato uno spostamento mentale, un cambiamento che enfatizza il comportamento del software rispetto all'implementazione. Portare il linguaggio ubiquitario in tutte le parti del processo di sviluppo è di grande beneficio e la BDD lo insegna. BDD ha un pubblico più vasto tester, manager, analisti.
Rachel Davis ha una bella spiegazione di BDD="Comprensione condivisa discutendo degli esempi". Quindi descrivi cosa vuoi che faccia il sistema e parla di alcuni esempi. Se vuoi saperne di più su questo argomento consulta questa discussione su uno dei blog padre di BDD: BDD è come TDD se ...
Penso che i sistemi BDD / TDD abbiano subito un cambiamento in quello che erano in origine, ma tuttavia hanno ancora i loro usi e sono complementari. I TDD tramite test unitari sono molto popolari oggi, ma l'aggiunta di BDD tramite qualcosa come Cucumber ti consente di guidare i tuoi componenti in un modo più focalizzato sull'utente. Oggi li considero come TDD come metodi per testare gli oggetti e BDD per testare le applicazioni / i componenti.
Puoi ancora fare BDD usando gli strumenti di test unitario (come credo fosse previsto) scrivendo i tuoi test e poi creando oggetti per soddisfarli (cioè non solo come granularità a livello di metodo), ma con strumenti di test basati su "storie" , puoi creare test di livello superiore che sono un po 'più evoluti rispetto all'utilizzo di strumenti di test unitario.
Leggi altre domande sui tag tdd bdd testing unit-testing