Relazione tra BDD e TDD

Qual è la relazione tra BDD e TDD?

Da quello che ho capito, BDD aggiunge due cose principali al TDD: i nomi dei test (assicurarsi / dovrei) ei test di accettazione. Devo seguire TDD durante lo sviluppo di BDD? In caso affermativo, i test delle unità TDD devono essere nominati nello stesso stile / garantire?

BDD aggiunge un ciclo attorno al ciclo TDD.

Quindi inizi con un comportamento e lasci 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, supponiamo che tu stia 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

Questa sintassi Given-And-When-And-Then-And è comune nello sviluppo guidato dal comportamento. Uno dei vantaggi è che può essere letto (e, con formazione, scritto) da non sviluppatori - ovvero, i tuoi stakeholder possono visualizzare l'elenco dei comportamenti che hai definito per completare con successo un'attività e vedere se soddisfa le loro aspettative molto prima di rilasciare un prodotto incompleto.

Esiste un linguaggio di scripting, noto come Gherkin, che assomiglia molto a quanto sopra e consente di scrivere codice di prova dietro le clausole in questi comportamenti. Dovresti cercare un traduttore basato su Gherkin per il tuo solito 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, perché qualcuno sta richiedendo una modifica?), Quindi stai fallendo questo test, sia che tu stia usando un test runner o semplicemente test manualmente.

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

Che tu stia scrivendo o meno BDD, 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. Passiamo ora il test comportamentale? In caso contrario, scrivere un altro test: ShouldRedirectToUserDefaultPage. Red-Green-Refactor fino a quando non sei felice. Lavare, risciacquare, ripetere fino a quando non si soddisfano 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 impedirlo per passare il tuo comportamento precedente. Dovresti fallire questo test a questo punto. Quindi torna indietro al tuo ciclo TDD.

E così via fino ad avere la tua pagina.

Consiglio vivamente The Rspec Book per saperne di più su BDD e TDD, anche se non sei uno sviluppatore di Ruby.

La mia comprensione:

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

Quindi, per affrontare il TDD fatto la parte giusta del BDD. BDD è iniziato come un cambiamento nella lingua di TDD per chiarire l'intenzione del processo. L'articolo introduttivo di Dan North su BDD spiega perché è utile concentrarsi sulla parola comportamento piuttosto che test: aiuta a confermare che non si sta solo costruendo il software giusto, ma si sta anche costruendo il software giusto. Questo faceva sempre parte di un buon approccio TDD, ma Dan lo codificò 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 loop / zoom-in zoom-out / outside-in. Descrivi innanzitutto il comportamento previsto della funzione (il loop esterno), quindi esegui lo zoom avanti sul loop interno per gestire le specifiche di basso livello.

Da http://www.metesreau.com/ncraft-workshop/

Cetriolino insieme a strumenti come Cucumber e SpecFlow fornisce un modo per scrivere quelle specifiche di funzionalità di alto livello e poi collegarle al codice che esegue il codice dell'applicazione. Direi che è qui che BDD potrebbe "sentirsi" diverso dal TDD, ma in realtà sta ancora facendo la stessa cosa, solo con un po 'di supporto per gli strumenti e un DSL. Un po 'più vicino al TDD' tradizionale 'sta usando strumenti come rspec, nspec, spock. Questi sembrano un po 'più simili allo stesso processo che faresti nel TDD "tradizionale" ma con un linguaggio più orientato al comportamento.

In BDD in Action di John Ferguson Smart (altamente raccomandato), sostiene un approccio a doppio loop, iniziando con qualcosa come jBehave alle specifiche eseguibili di livello esterno, quindi inserendo uno strumento come Spock per le specifiche di basso livello.

BDD avvicina il concetto di test driven agli stakeholder aziendali. Gherkin è progettato per essere leggibile dal punto di vista commerciale e l'idea di "documentazione vivente", ovvero di rapporti di avanzamento prodotti automaticamente dalle vostre specifiche eseguibili, consiste nel fornire feedback agli stakeholder.

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

Per la risposta canonica su questo, potrebbe essere meglio andare di nuovo a Dan North . Se il tuo team è composto da sviluppatori, BDD = TDD. Se il tuo team coinvolge tutta una serie di parti interessate, BDD è più vicino a XP, con TDD che ne fa parte.

Qual è la relazione tra BDD e TDD?

Sono la stessa cosa.

Da quello che ho capito BDD aggiunge due cose principali su TDD: test di denominazione (assicurarsi / dovrebbe)

Non è proprio qualcosa che BDD "aggiunge". È solo una convenzione diversa che ha lo scopo di facilitare l'insegnamento e la comprensione del TDD.

Le persone che hanno creato BDD insegnavano TDD e hanno notato che la cosa più difficile da capire era che TDD non ha 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 divorziare dal pensare ai test , quando la parola "test" (o la terminologia correlata come "assert") appare praticamente ovunque . Quindi hanno scambiato alcune parole.

Ma sono solo le parole! Non vi è alcuna differenza effettiva tra TDD e BDD.

e test di accettazione.

I test di accettazione sono una parte tanto importante del TDD quanto del BDD. Ancora: non c'è differenza tra TDD e BDD: TDD fatto bene è BDD, BDD è TDD fatto bene.