Quali vantaggi ci sono nell'usare uno strumento di test BDD come SpecFlow su semplici strumenti di test unitari come MSTest?

Il termine "BDD" è stato coniato da alcuni professionisti del TDD per risolvere un problema specifico : quando si insegna TDD, il più importante ostacolo da superare, è capire che TDD non si tratta di test.

Dan North si è reso conto che un problema nel capire che TDD non è il test, è che tutto ti urla "TEST": stai usando un test framework per scrivere test cases ereditando da una classe chiamata TestCase e scrivendo metodi test il cui nome inizia con test . Usi la terminologia di testing ovunque: "assertion", per esempio. Quindi pensò: cosa succede se rimuoviamo semplicemente tutte le parole che riguardano il test e le sostituiamo con parole correlate alle specifiche del comportamento tramite esempi? È ancora esattamente la stessa cosa, tranne senza le parole fuorvianti!

E questo è esattamente quello che è uno strumento BDD: è lo stesso di uno strumento TDD, ma senza la terminologia di test. È così che Dan North ha scritto JBehave, per esempio. Se comprendi già TDD e comprendi che TDD non riguarda il test, allora non importa quale strumento utilizzi. Ma personalmente, trovo più facile entrare nella mentalità che non sto scrivendo test, quando sono, beh, non sto scrivendo test ma piuttosto esempi. Quindi, per me, gli strumenti BDD sono più facili da usare, quando uso gli strumenti TDD, sono costantemente in lotta con me stesso "So che questo è chiamato un test , ma non è uno, è un < em> esempio , stupido cervello! "

Questo è ancora più pronunciato se mostri i tuoi test a qualcun altro, ad es. uno stakeholder non tecnico. Potresti spiegare loro che mentre questo assomiglia ad un test, non è realmente un test ma piuttosto un esempio del comportamento ... oppure potresti usare un framework che lo fa apparire come un esempio del comportamento. The Great Dream ™ che le parti interessate non tecniche scriverebbero le specifiche eseguibili non si è avverato, ma conosco diverse organizzazioni in cui le parti interessate non tecniche abitualmente leggono e talvolta persino edit Esempi di Gherkin, anche se non li stanno scrivendo da zero. Obie Fernandez ha scritto una volta un editor strutturale basato sul web per Cucumber (che probabilmente non funziona più) che consentirebbe agli utenti non tecnici di modificare gli scenari Cucumber in modo strutturato e li eseguirà immediatamente contro il codebase e i suoi clienti non tecnici in realtà ha usato questo editor per scrivere nuovi scenari e comunicare i loro desideri sotto forma di esempi eseguibili.

tl; dr : TDD non tratta di test, BDD è TDD senza la terminologia di testing, gli strumenti BDD sono strumenti di test senza la terminologia di testing. Se riesci a gestire il divorzio mentale dai test mentre usi la terminologia di test, non importa ciò che usi. Tuttavia, tieni presente che potresti non essere l'unico cliente di quei "test", anche se sei l'unico a scriverli, potresti non essere l'unico a leggerli.

La prima cosa da sapere è che la persona che ha coniato il termine BDD (Dan North) non usa tali strumenti. Usa gli strumenti di test unitari standard.

Il presunto vantaggio è la facilità di trasformare l'inglese strutturato (o un'altra lingua) in codice. Inglese strutturato significa che gli stakeholder possono usare l'inglese semplice per dare i loro requisiti, ma in un modo che è il codice relativo agli sviluppatori.

Dico presunto vantaggio perché in passato ho scoperto che: a) la maggior parte delle parti interessate non impara né cerca di imparare ad esprimere le proprie esigenze in modo strutturato (cerchiamo di imporre loro un sistema per il quale di solito non fanno " vedere i benefici); e b) tali strumenti tendono a rendere effettivamente più difficile la creazione di test.

Ho usato Specflow per due anni prima di scartare completamente l'idea e tornare alla normale NUnit.

Sarà difficile ottenere una risposta che ti soddisfi, perché tutti quelli che stanno rispondendo sono prevenuti in qualche modo (incluso me stesso ovviamente).

Penso (o almeno spero) che l'hype non riguardi gli strumenti BDD che possono essere usati "invece di" strumenti di test unitari, ma riguardo al processo BDD.

Il processo BDD ti chiede di pensare al problema che vorresti risolvere per primo, trovare alcuni buoni esempi e solo saltare alla codifica in seguito, usando questi esempi come test.

Gli strumenti BDD DSL esterni, come Cucumber o SpecFlow, utilizzano il file di testo semplice per aiutarti a strutturare i tuoi pensieri e discuterne con i rappresentanti aziendali senza la distrazione della codifica.

Il mio insegnante di matematica è stato in grado di disegnare a mano una linea dello stretto perfetto. Uso un righello se ho bisogno di pescarne uno. Questo è lo stesso con gli strumenti BDD. Se è possibile concentrarsi sugli esempi e discuterli con il business, è possibile acquisirli in test unitari ben strutturati e denominati. Va bene.

Ma - per quanto riguarda la mia esperienza - per molti team che hanno questa separazione è vantaggioso. Questo è il loro sovrano.

Una volta che si pratica, l'overhead di mappare l'inglese ai pezzi del codice di automazione e mantenerlo non è così grande come sembra. Oggigiorno ho persino acquisito test con SpecFlow per alcuni miei progetti interni, di una sola persona, perché mi aiuta a sapere se ho il mio sviluppatore o il mio proprietario del prodotto.