Quali sono le differenze principali tra TDD e BDD?

Question

Il Test Driven Development è stato di gran moda nella comunità .NET negli ultimi anni.Recentemente ho sentito lamentele nella comunità ALT.NET riguardo BDD.Che cos'è?Cosa lo rende diverso dal TDD?

Answer 1

Capisco che BDD sia più importante specifica di test.È collegato al Domain Driven Design (non ami questi acronimi *DD?).

È collegato a un certo modo di scrivere le storie degli utenti, inclusi test di alto livello.Un esempio di Tom dieci Thij:

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

(Nel suo articolo, Tom prosegue eseguendo direttamente questa specifica di test in Ruby.)

Il papa di BDD lo è Dan Nord.Troverai un'ottima introduzione nella sua Presentazione di BDD articolo.

In questo troverai un confronto tra BDD e TDD video.Anche un'opinione su BDD come "TDD fatto bene" di Jeremy D.Mugnaio

Aggiornamento del 25 marzo 2013

Il video sopra manca da un po'.Eccone uno recente di Llewellyn Falco, BDD vs TDD (spiegazione).Trovo che la sua spiegazione sia chiara e pertinente.

Answer 2

Per me la differenza principale tra BDD e TDD è il focus e la formulazione.E le parole sono importanti per comunicare le tue intenzioni.

TDD concentra l'attenzione sui test.E poiché nel "vecchio mondo a cascata" i test vengono eseguiti dopo l'implementazione, questa mentalità porta a una comprensione e a un comportamento errati.

Il BDD dirige l'attenzione sul comportamento e sulle specifiche, quindi le menti a cascata vengono distratte.Quindi BDD è più facilmente intesa come pratica di progettazione e non come pratica di test.

Answer 3

Sembra che esistano due tipi di BDD.

Il primo è lo stile originale di cui parla Dan North e che ha causato la creazione dei framework di stile xBehave.Per me questo stile è applicabile principalmente per test di accettazione o specifiche rispetto a oggetti di dominio.

Il secondo stile è quello reso popolare da Dave Astels e che, per me, è una nuova forma di TDD che presenta alcuni seri vantaggi.Si concentra sul comportamento piuttosto che sui test e anche su piccole classi di test, cercando di arrivare al punto in cui sostanzialmente hai una riga per metodo di specifica (test).Questo stile si adatta a tutti i livelli di test e può essere eseguito utilizzando qualsiasi framework di test unitario esistente sebbene i framework più recenti (stile xSpec) aiutino a focalizzare il comportamento piuttosto che il test.

C'è anche un gruppo BDD che potresti trovare utile:

http://groups.google.com/group/behaviordrivendevelopment/

Answer 4

Sviluppo guidato dai test è una metodologia di sviluppo software test-first, il che significa che richiede la scrittura del codice di test prima di scrivere il codice effettivo che verrà testato.Nelle parole di Kent Beck:

Lo stile qui è quello di scrivere alcune righe di codice, quindi un test che dovrebbe funzionare, o anche meglio, per scrivere un test che non eseguirà, quindi scrivere il codice che lo farà funzionare.

Dopo aver capito come scrivere un piccolo pezzo di codice, ora, invece di semplicemente codificare, vogliamo ottenere un feedback immediato e praticare un po 'di codice, testare un po', codice un po ', testare un po'. " Quindi scriviamo immediatamente un test per questo.

Quindi TDD è una metodologia tecnica di basso livello che i programmatori utilizzano per produrre codice pulito che funzioni.

Sviluppo guidato dal comportamento è una metodologia che è stata creata sulla base di TDD, ma si è evoluta in un processo che non riguarda solo programmatori e tester, ma si occupa invece dell'intero team e di tutti gli stakeholder importanti, tecnici e non tecnici.BDD è partito da alcune semplici domande a cui TDD non risponde bene:quanti test dovrei scrivere?Cosa dovrei effettivamente testare e cosa non dovrei?Quali dei test che scrivo saranno effettivamente importanti per l'azienda o per la qualità complessiva del prodotto e quali sono solo la mia eccessiva ingegneria?

Come puoi vedere, tali domande richiedono la collaborazione tra tecnologia e business.Le parti interessate aziendali e gli esperti di settore spesso possono dire agli ingegneri che tipo di test sembrano utili, ma solo se i test sono test di alto livello che trattano importanti aspetti aziendali.BDD chiama questi test di tipo professionale "esempi", come in "dimmi un esempio di come questa funzionalità dovrebbe comportarsi correttamente" e riserva la parola "test" per controlli tecnici di basso livello come la convalida dei dati o il test delle integrazioni API.La parte importante è che mentre test può essere creato solo da programmatori e tester, esempi possono essere raccolti e analizzati dall'intero team di consegna: progettisti, analisti e così via.

In una frase, una delle migliori definizioni di BDD che ho trovato Finora è che BDD riguarda "avere conversazioni con esperti di dominio e usare esempi per ottenere una comprensione condivisa del comportamento desiderato e scoprire incognite". La parte di scoperta è molto importante.Man mano che il team di consegna raccoglie più esempi, inizia a comprendere sempre di più l'ambito aziendale e quindi riduce la propria incertezza su alcuni aspetti del prodotto con cui deve confrontarsi.Man mano che l’incertezza diminuisce, aumentano la creatività e l’autonomia del team di consegna.Ad esempio, ora possono iniziare a suggerire i propri esempi che gli utenti aziendali non ritenevano possibili a causa della loro mancanza di competenze tecnologiche.

Ora, avere conversazioni con esperti di business e di dominio sembra fantastico, ma sappiamo tutti come spesso va a finire nella pratica.Ho iniziato il mio viaggio con la tecnologia come programmatore.Come programmatori, ci viene insegnato scrivere il codice—algoritmi, modelli di progettazione, astrazioni.Oppure, se sei un designer, ti viene insegnato progetto—organizzare le informazioni e creare bellissime interfacce.Ma quando otteniamo i nostri lavori entry-level, i nostri datori di lavoro si aspettano che "offriamo valore ai clienti". E tra questi clienti può essere, ad esempio ...una banca.Ma non sapevo quasi nulla di operazioni bancarie, tranne come ridurre in modo efficiente il saldo del mio conto.Quindi dovrei in qualche modo tradurre in codice ciò che ci si aspetta da me...Dovrei costruire un ponte tra il settore bancario e le mie competenze tecniche se voglio fornire valore.BDD mi aiuta a costruire un ponte di questo tipo su una base stabile di comunicazione fluida tra il team di consegna e gli esperti del settore.

Saperne di più

Se vuoi saperne di più sul BDD, ho scritto un libro sull'argomento. “Scrivere ottime specifiche” esplora l'arte di analizzare i requisiti e ti aiuterà a imparare come costruire un ottimo processo BDD e utilizzare gli esempi come parte fondamentale di tale processo.Il libro parla del linguaggio onnipresente, raccogliendo esempi e creando le cosiddette specifiche eseguibili (test automatizzati) a partire dagli esempi: tecniche che aiutano i team BDD a fornire ottimi software in tempo e nel rispetto del budget.

Se sei interessato ad acquistare "Scrivere ottime specifiche", puoi risparmiare il 39% con il codice promozionale 39nicieja2 :)

Answer 5

Ho sperimentato un po' l'approccio BDD e la mia conclusione prematura è che BDD è adatto all'implementazione dei casi d'uso, ma non sui dettagli sottostanti.I TDD oscillano ancora a quel livello.

BDD viene utilizzato anche come strumento di comunicazione.L'obiettivo è scrivere specifiche eseguibili che possano essere comprese dagli esperti del settore.

Answer 6

Mi sembra che BDD abbia un ambito più ampio.Ciò implica quasi che venga utilizzato il TDD, che BDD sia la metodologia comprensiva che raccoglie le informazioni e i requisiti per l'utilizzo, tra le altre cose, delle pratiche TDD per garantire un feedback rapido.

Answer 7

Con le mie ultime conoscenze in BDD rispetto a TDD, BDD si concentra sulla specifica di cosa accadrà dopo, mentre TDD si concentra sulla creazione di una serie di condizioni e quindi sull'esame dell'output.

Answer 8

Lo sviluppo basato sul comportamento sembra concentrarsi maggiormente sull'interazione e sulla comunicazione tra sviluppatori e anche tra sviluppatori e tester.

L'articolo di Wikipedia ha una spiegazione:

Sviluppo guidato dal comportamento

Io però non pratico il BDD.

Answer 9

Considera il vantaggio principale del TDD come design.Dovrebbe chiamarsi Test Driven Design.BDD è un sottoinsieme di TDD, chiamalo Behavior Driven Design.

Consideriamo ora un'implementazione popolare di TDD - Unit Testing.Le unità in Unit Testing sono in genere un bit di logica che è l'unità di lavoro più piccola che puoi realizzare.

Quando metti insieme queste unità in modo funzionale per descrivere il comportamento desiderato alle macchine, devi comprendere il comportamento che stai descrivendo alla macchina.La progettazione guidata dal comportamento si concentra sulla verifica della comprensione da parte degli implementatori dei casi d'uso/requisiti/qualsiasi cosa e verifica l'implementazione di ciascuna funzionalità.BDD e TDD in generale hanno l'importante scopo di informare la progettazione e il secondo scopo di verificare la correttezza dell'implementazione, soprattutto quando cambia.Il BDD fatto bene coinvolge biz e dev (e qa), mentre il test unitario (probabilmente visto erroneamente come TDD piuttosto che come un tipo di TDD) viene generalmente eseguito nel silo di sviluppo.

Aggiungo che i test BDD servono come requisiti di vita.

Answer 10

BDD è in gran parte TDD fatto bene.Tuttavia, c'è un valore aggiuntivo offerto da BDD.Ecco un link a riguardo:

BDD è più di un “TDD fatto bene”

Answer 11

Ecco la rapida istantanea:

• TDD è solo il processo di test del codice prima di scriverlo!

• DDD è il processo di informazione sul Dominio prima di ogni ciclo di tocco del codice!

• BDD è un'implementazione di TDD che introduce alcuni aspetti di DDD!

Spero che aiuti!

Answer 12

Differenza tra sviluppo basato sui test (TDD) e sviluppo guidato dal comportamento (BDD)

• BDD si concentra sull'aspetto comportamentale del sistema piuttosto che su quello
  aspetto implementativo del sistema su cui si concentra TDD.

• BDD fornisce una comprensione più chiara di ciò che il sistema dovrebbe fare
  dal punto di vista dello sviluppatore e del cliente.Solo TDD
  fornisce allo sviluppatore una comprensione di ciò che il sistema dovrebbe fare.

• BDD consente sia allo sviluppatore che al cliente di lavorare insieme per l'analisi dei requisiti contenuti nel codice sorgente del sistema.

Answer 13

Non c'è differenza tra TDD e BDD.tranne che puoi leggere meglio i tuoi test e puoi usarli come requisiti.Se scrivi i tuoi requisiti con le stesse parole con cui scrivi i test BDD, puoi venire dal tuo cliente con alcuni dei tuoi test definiti pronti per scrivere codice.