Test-Driven Development è 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 è scrivere alcune righe di codice, quindi un test che dovrebbe essere eseguito, o ancora meglio, scrivere un test che non verrà eseguito, quindi scrivere il codice che lo farà funzionare.
Dopo aver capito come scrivere un piccolo pezzo di codice, ora, invece di limitarci a programmare, vogliamo ottenere un feedback immediato ed esercitarci "codifica un po ', prova un po', codifica un po ', prova un po'". Quindi scriviamo immediatamente un test per questo.
Quindi TDD è una metodologia tecnica di basso livello che i programmatori usano per produrre codice pulito che funzioni.
Lo sviluppo guidato dal comportamento è una metodologia che è stata creata sulla base di TDD, ma si è evoluta in un processo che non riguarda solo i programmatori e i tester, ma si occupa invece dell'intero team e di tutti i principali stakeholder, tecnici e non tecnici. BDD è partito da alcune semplici domande alle quali TDD non risponde bene: quanti test devo scrivere? Cosa dovrei effettivamente testare e cosa non dovrei? Quale dei test che scrivo sarà in effetti importante per l'azienda o per la qualità generale del prodotto e quali sono solo la mia eccessiva ingegneria?
Come puoi vedere, tali domande richiedono la collaborazione tra tecnologia e business. Gli stakeholder aziendali e gli esperti di dominio spesso possono dire agli ingegneri che tipo di test sembra essere utile, ma solo se i test sono test di alto livello che trattano importanti aspetti aziendali. BDD chiama "esempi" di test di tipo aziendale come "dimmi un esempio di come questa funzionalità dovrebbe funzionare 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 i test possono essere creati solo da programmatori e tester, gli esempi possono essere raccolti e analizzati da tutto il team di consegna — da 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, iniziano a comprendere sempre di più il dominio aziendale e quindi riducono la loro incertezza su alcuni aspetti del prodotto che devono affrontare. Quando 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 pensavano fossero possibili a causa della loro mancanza di competenza tecnica.
Ora, avere conversazioni con gli esperti di business e di dominio suona alla grande, ma sappiamo tutti come spesso finisce in pratica. Ho iniziato il mio viaggio con la tecnologia come programmatore. Come programmatori, ci viene insegnato a scrivere codice: algoritmi, schemi di progettazione, astrazioni. Oppure, se sei un designer, ti viene insegnato progettare—Organizzare le informazioni e creare bellissime interfacce. Ma quando otteniamo i nostri lavori entry-level, i nostri datori di lavoro si aspettano che "consegniamo valore ai clienti". E tra questi clienti può esserci, per esempio ... una banca. Ma non sapevo quasi nulla del settore bancario, tranne come ridurre efficacemente il saldo del mio conto. Quindi dovrei in qualche modo tradurre ciò che ci si aspetta da me in codice ... Dovrei costruire un ponte tra il settore bancario e la mia competenza tecnica se voglio fornire qualsiasi valore. BDD mi aiuta a costruire un tale ponte su una base stabile di comunicazione fluida tra il team di consegna e gli esperti del dominio.
Per saperne di più
Se vuoi leggere di più su BDD, ho scritto un libro sull'argomento. "Scrivere grandi specifiche" esplora l'arte dell'analisi dei requisiti e ti aiuterà a imparare come costruire un ottimo processo BDD e usare esempi come parte centrale di quel processo. Il libro parla del linguaggio onnipresente, raccogliendo esempi e creando dagli esempi esempi di cosiddette specifiche eseguibili (test automatizzati), tecniche che aiutano i team BDD a distribuire software di qualità eccezionale in tempo e budget.
Se sei interessato all'acquisto di "Scrivere grandi specifiche" , puoi risparmiare il 39% con il codice promozionale 39nicieja2 :)