SpecFlow/BDD per i test delle unità?

Question

Sembra che Internet non abbia una risposta definitiva, o un insieme di principi per aiutarmi a rispondere alla domanda. Quindi mi rivolgo al grande folk su SO per aiutarmi a trovare risposte o pensieri guida :)

SpecFlow è molto utile per BDD in .NET. Ma quando parliamo di BDD stiamo solo parlando di test di integrazione/accettazione, o stiamo anche parlando di unit test - un sostituto totale per TDD?

L'ho usato solo su piccoli progetti, ma trovo che anche per i miei test di unità, SpecFlow migliora la documentazione del codice e il pensiero in termini di linguaggio. Di converseley, non riesco a vedere il codice completo per un test in un unico posto, poiché i passaggi sono frammentati.

Ora a te ..........

EDIT: Ho dimenticato di dire che vedo RSpec nella comunità RoR che usa la sintassi in stile BDD per unit testing.

Answer 1

Ho recentemente iniziato a utilizzare SpecFlow per il mio test BDD, ma inoltre, utilizzo ancora i test di unità e integrazione.

Fondamentalmente, ho diviso i test in progetti separati:

• Spec
• Integrazione
• Unità

mio test di unità sono per testare un singolo metodo e non eseguono alcun database chiamate o riferimenti esterni di sorta. Io uso i test di integrazione per le chiamate a metodo singolo (forse qualche volta) che interagiscono con risorse esterne, come un database, servizio web, ecc.

Uso BDD per descrivere test che imitano i requisiti aziendali/di dominio di il progetto. Ad esempio, avrei le specifiche per la funzione di generazione della fattura di un progetto; o per lavorare con un carrello della spesa. Questi test seguono la

Come utente, voglio, Al fine di

tipo di semantica.

Il mio consiglio è di dividere i test in base alle proprie esigenze. Evitare di provare a eseguire il test dell'unità usando SpecFlow.

Answer 2

Lo vedo come un test di integrazione che significa che non sostituisce i casi di test dell'unità scritti come parte del processo TDD. Qualcuno avrà un'opinione diversa su questo. Il test case dell'unità IMHO verifica solo i metodi/funzioni e tutte le dipendenze devono essere prese in giro e iniettate. Quando si tratta di test di integrazione, si invieranno dipendenze reali invece che derise. È possibile eseguire gli stessi test di integrazione con i framework di test delle unità, ma il BDD fornisce un modo più semplice di spiegare il caso di utilizzo del test di integrazione in una lingua specifica del dominio che è un inglese semplice (o qualsiasi lingua localizzata).

Ta,
Rajeesh

Answer 3

Alla fine stiamo cercando di fornire al cliente esattamente ciò che il cliente vuole e come tale io davvero non vedo la necessità di scrivere unit test, oltre a SpecFlow. Dopo tutto, esercita la stessa base di codice.Sono abbastanza nuovo a BDD/ATDD/TDD ma oltre ad essere "completo" e strettamente aderente a TDD, trovo che non sia necessario scrivere più test unitari.

Ora suppongo che se il team fosse disperso e lo sviluppatore non fosse in grado di eseguire l'intera applicazione, sarebbero necessari test di unità separati ma dove lo sviluppatore/i ha accesso all'intero codice base ed è in grado di eseguire il applicazione, quindi perché preoccuparsi di scrivere più test.

Answer 4

Ho utilizzato specflow per il test BDD su due diverse applicazioni di buone dimensioni. Una volta elaborati i nodi delle convenzioni di denominazione della frase, ha funzionato abbastanza bene. BA e QA e persino stagisti potrebbero scrivere test BDD per l'applicazione.

Tuttavia, l'ho usato anche per i test unitari. Eresia! Posso sentire qualcuno di voi urlare. Tuttavia, c'erano MOLTE buone ragioni per questo. Il sistema era responsabile della realizzazione di molti calcoli o determinazioni basati su molti dati diversi. Con molti test unitari che richiedono l'immissione di tutti questi dati per scopi di test, rende MOLTO più facile gestire i dati utilizzati per i test unitari tramite il formato tabella fornito da specflow. Sfruttare efficacemente il repository dei dati in formato tabella, consentendo di testare con vigore i diversi componenti.

Non so se lo farei in ogni caso, ma in quelli per cui l'ho usato, ha reso i volumi di dati necessari per eseguire i test unitari in modo molto più semplice e chiaro.

Answer 5

Abbiamo iniziato a utilizzare Specflow anche per i nostri test di unità.

Il motivo principale (e il vantaggio) di questo è che scopriamo che ti costringe a scrivere i test da un punto di vista del comportamento, che a sua volta ti costringe a scrivere in un modo agnostico più implementazione e questo alla fine si traduce in test meno amichevoli e più reattivi.

Sicuramente questo può essere fatto anche con framework di test unitari standard, ma non siete guidati così facilmente come abbiamo scoperto che stiamo usando specflow e la sintassi del gherkin.

Ci sono alcune impostazioni generali per lo specflow, ma troviamo che questo viene rapidamente ripagato quando si eseguono alcuni test (a causa della significativa riusabilità del passo che è possibile ottenere con specflow) o è necessario ridefinire l'implementazione.

In più si ottengono delle belle specifiche leggibili che sono facili da comprendere per i neofiti del team.

Answer 6

Dato:

• test unitari sono prova (piccoli) "unità di codice"
• Il cliente di più “unità di codici” sono altri programmatori.
• Parte del motivo per cui un test dell'unità è fornire un esempio di come chiamare il codice.

Pertanto:

• Chiaramente unit test dovrebbero normalmente essere scritte nel linguaggio di programmazione che gli utenti della “unità di codice” chiameranno con.

Tuttavia:

• A volte le tabelle di dati sono necessari per impostare le condizioni di uno unit test viene eseguito in
• maggior parte dei quadri di unit test non sono bravi a usare tabelle di dati..

Pertanto:

• Specflow può essere l'opzione migliore per alcuni test di unità, ma non dovrebbe essere scegliere il default.