Relazione tra BDD e TDD

BDD aggiunge un ciclo attorno al ciclo TDD.

Quindi inizi con un comportamento e lascia che guidi i tuoi test, quindi lascia che i test guidino lo sviluppo. Idealmente, BDD è guidato da una sorta di test di accettazione, ma non è necessario al 100%. Finché hai definito il comportamento previsto, stai bene.

Quindi, diciamo che stai scrivendo una pagina di accesso.

Inizia con il percorso felice:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

La sintassi Given-And-When-And-Then-And è comune nello sviluppo basato sul comportamento. Uno dei vantaggi di questo è che può essere letto (e, con formazione, scritto) da non-sviluppatori - cioè, i tuoi stakeholder possono visualizzare l'elenco di comportamenti che hai definito per il completamento di un compito con successo e vedere se esso corrisponde alle loro aspettative molto prima che tu rilasci un prodotto incompleto.

Esiste un linguaggio di scripting, noto come Gherkin, che assomiglia molto a quanto sopra e consente di scrivere codice di test dietro le clausole di questi comportamenti. Dovresti cercare un traduttore basato su Gherkin per il tuo normale framework di sviluppo. Questo è fuori dallo scopo di questa risposta.

Comunque, torniamo al comportamento. La tua attuale applicazione non lo fa ancora (se lo fa allora perché qualcuno richiede una modifica?), Quindi stai fallendo questo test, sia che tu stia utilizzando un test runner o semplicemente test manualmente.

Quindi ora è il momento di passare al ciclo TDD per fornire quella funzionalità.

Sia che tu stia scrivendo BDD o meno, i tuoi test dovrebbero essere nominati con una sintassi comune. Uno dei più comuni è la sintassi "dovrebbe" che hai descritto.

Scrivi un test: ShouldAcceptValidDetails. Passa attraverso il ciclo Red-Green-Refactor fino a quando non sei soddisfatto. Ora passiamo il test del comportamento? In caso contrario, scrivere un altro test: ShouldRedirectToUserDefaultPage. Red-Green-Refactor fino a che sei felice. Lavare, risciacquare, ripetere fino a soddisfare i criteri stabiliti nel comportamento.

E poi passiamo al comportamento successivo.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Ora non avresti dovuto anticiparlo per passare il tuo comportamento precedente. Dovresti fallire questo test a questo punto. Quindi torna al tuo ciclo TDD.

E così via fino alla tua pagina.

Consiglia caldamente Il libro Rspec per saperne di più su BDD e TDD, anche se non lo sei uno sviluppatore di Ruby.

La mia comprensione di questo:

• BDD è iniziato come rebranding del TDD per rendere più chiara l'attenzione sul comportamento.
• Fornisce un supporto più formale (DSL e strumenti) per concentrarsi sul comportamento e sulle specifiche dell'eseguibile.
• BDD può ora essere visto come un superset di TDD ,. È cresciuto nel tempo per comprendere più aspetti del lato elicitistico delle cose, ma il lato del processo di sviluppo è ancora una parte fondamentale.

Quindi per affrontare il TDD fatto parte giusta del BDD. BDD è iniziato come un cambiamento nel linguaggio di TDD per rendere chiara l'intenzione del processo. L'articolo introduttivo di Dan North su BDD spiega perché è utile concentrarsi sulla parola comportamento piuttosto che sul test - aiuta a confermare che non si è solo costruendo il software giusto, stai anche costruendo il software giusto. Questo è sempre stato parte di un buon approccio TDD, ma Dan lo ha codificato un po 'in BDD.

Ciò che penso BDD rende un po 'più esplicito di TDD, o almeno formalizza e fornisce supporto per gli strumenti, è questo approccio a due cicli / doppio anello / zoom indietro / esterno-in. Per prima cosa descrivi il comportamento previsto della feature (il loop esterno), quindi esegui l'ingrandimento del loop interno per gestire le specifiche di basso livello.

Dal link

Gherkin in combinazione con strumenti come Cucumber e SpecFlow fornisce un modo per scrivere quelle specifiche di funzionalità di alto livello e quindi collegarle al codice che esegue il codice dell'applicazione. Direi che questo è il punto in cui il BDD potrebbe "sentirsi" diverso dal TDD, ma in realtà sta ancora facendo la stessa cosa, solo con alcuni strumenti aggiuntivi supportati e una DSL. Un po 'più vicino al TDD "tradizionale" sta usando strumenti come rspec, nspec, spock. Questi ritengono un po 'più simile allo stesso processo che faresti nel TDD "tradizionale" ma con un linguaggio più orientato al comportamento.

In BDD in azione di John Ferguson Smart (altamente raccomandato), sostiene un doppio ciclo approccio, a partire da qualcosa come jBehave alle specifiche eseguibili di livello esterno, quindi cadere in uno strumento come Spock per le specifiche di basso livello.

BDD porta il concetto di test-driven più vicino agli stakeholder aziendali. Gherkin è progettato per essere leggibile dal mondo degli affari e l'idea di "documentazione vivente", cioè di generare automaticamente rapporti sui progressi delle specifiche eseguibili, consiste nel fornire un feedback agli stakeholder.

Un'altra parte del BDD ora, che è dove diventa veramente qualcosa che incorpora TDD come parte di un processo più ampio, sono i requisiti che elicitano pezzi e pezzi. Idee come Feature Injection, Impact Mapping e Real Options fanno parte di questo lato.

Per la risposta canonica su questo, potrebbe essere meglio andare a Dan Nord nuovo . Se la tua squadra è tutti gli sviluppatori, allora BDD = TDD. Se il tuo team coinvolge un'intera gamma di parti interessate, BDD è più vicino a XP, con TDD che ne fa parte.

What is the relation of BDD and TDD?

Sono la stessa cosa.

From what I understood BDD adds two main things over TDD: tests naming (ensure/should)

Questo non è proprio qualcosa che BDD "aggiunge". È solo una convenzione diversa intesa a facilitare l'insegnamento e la comprensione del TDD.

Le persone che hanno creato BDD stavano insegnando a TDD e hanno notato che la cosa più difficile da capire era che TDD non aveva assolutamente nulla a che fare con i test. Una volta che gli studenti hanno superato quell'ostacolo, è diventato molto più facile per loro. Ma è molto difficile separarsi dal pensare a test , quando la parola "test" (o terminologia correlata come "assert") appare praticamente ovunque . Quindi, hanno scambiato alcune parole.

Ma è solo le parole! C'è no differenza effettiva tra TDD e BDD.

and acceptance tests.

I test di accettazione sono una parte altrettanto importante del TDD così come lo sono del BDD. Ancora: non c'è differenza tra TDD e BDD: TDD fatto bene è BDD, BDD è TDD fatto bene.