Qual è il BDD Framework più maturo per .NET? [chiuso]

Question

Abbiamo usato BDD - Behavior Driven Development (dal punto di vista di Dan North) come meccanismo registrare i test di accettazione degli utenti e guidare lo sviluppo di un paio di progetti, con discreto successo. Fino ad oggi, tuttavia, non abbiamo automatizzato i test stessi.

Ora sto cercando di automatizzare i test, ma non sono sicuro del framework di comportamento da sostenere. Finora NBehave sembra essere il precursore - ma ce ne sono altri che dovrei guardare? C'è un chiaro "vincitore" al momento?

Answer 1

La risposta rapida

Un punto molto importante da evidenziare è che ci sono due tipi di sviluppo guidato dal comportamento. I due tipi sono xBehave e xSpec .

xBehave BDD: SpecFlow

SpecFlow (molto simile a cetriolo dallo stack di Ruby) è eccellente nel facilitare i test BDD xBehave come criteri di accettazione. Non fornisce tuttavia un buon modo per scrivere test comportamentali a livello di unità. Esistono alcuni altri framework di test xBehave, ma SpecFlow ha ottenuto molta trazione.

xSpec BDD: MSpec

Obiettivamente parlando. Dati i framework di specifiche di contesto disponibili, MSpec è stato il più lungo ed è il framework di contesto / specifiche più utilizzato nella comunità .Net.

L'altro framework BDD xSpec: NSpec

Personalmente consiglierei NSpec (ispirato direttamente da RSpec per Ruby). Informativa completa, sono uno degli autori di NSpec. Puoi realizzare BDD semplicemente usando NUnit o MSTest ... ma in qualche modo non riescono (è davvero difficile costruire contesti in modo incrementale). MSpec è anche un'opzione ed è la struttura di contesto / specifica più matura per. Netto. Ma , ci sono solo alcune cose che sono più semplici in NSpec.

La risposta lunga

I due tipi di BDD esistono principalmente a causa dei benefici ortogonali che forniscono.

Pro e contro di xBehave (sintassi GWT)

Pro

• aiuta a facilitare le conversazioni con l'azienda attraverso un dialetto comune chiamato (ad es. Given ...., And Given ...., When ......, And When ....., Then .. .., E poi)
• il dialetto comune può quindi essere mappato su codice eseguibile che dimostra all'azienda che hai effettivamente finito quello che hai detto che avresti finito
• il dialetto è restrittivo, quindi l'azienda deve chiarire i requisiti e adattarla alle frasi.

Contro

• Sebbene l'approccio xBehave sia utile per guidare criteri di accettazione di alto livello, i cicli necessari per mappare l'inglese al codice eseguibile tramite attributi lo rendono impossibile per scacciare un dominio a livello di unità.
• La mappatura del dialetto comune ai test è PAINFUL (aumenta il tuo regex). Ogni frase creata dall'azienda deve essere mappata su un metodo eseguibile tramite attributi.
• Il dialetto comune deve essere strettamente controllato in modo che la gestione della mappatura non sfugga di mano. Ogni volta che cambi una frase, devi trovare un metodo che si collega direttamente a quella frase e correggere la corrispondenza regex.

Pro e contro di xSpec (Contesto / Specifiche)

Pro

• Consente allo sviluppatore di creare un contesto in modo incrementale. Un contesto può essere impostato per un test e alcune asserzioni possono essere eseguite su quel contesto. È quindi possibile specificare più contesto (basandosi sul contesto già esistente) e quindi specificare più test.
• Nessun linguaggio restrittivo. Gli sviluppatori possono essere più espressivi sul comportamento di una determinata parte di un sistema.
• Non è necessaria alcuna mappatura tra l'inglese e un dialetto comune (perché non ce n'è uno).

Contro

• Non così accessibile dall'azienda. Ammettiamolo, all'azienda non piace chiarire ciò che vogliono. Se avessimo dato loro un approccio contestuale al BDD, la frase avrebbe semplicemente letto " Fallo funzionare "
• Tutto è nel codice. La documentazione di contesto è intrecciata all'interno del codice (ecco perché non dobbiamo preoccuparci di mappare l'inglese al codice)
• Non così leggibile dato un meno restrittivo

Answer 2

Scopri SpecFlow .

È uno strumento ispirato a Cucumber che mira a fornire un approccio pragmatico e privo di attriti allo sviluppo guidato dai test di accettazione e allo sviluppo guidato dai comportamenti per i progetti .NET oggi.

L'integrazione con VisualStudio sembra particolarmente promettente.

Answer 3

StoryQ sembra una bella alternativa a NBehave con la sua interfaccia fluida. Lo darei sicuramente.

Answer 4

Non credo ci sia davvero un "vincitore". Altri framework includono SpecUnit.NET e il progetto MSpec si sta dimostrando promettente anche con il inizi di un Gallio adattatore. Tecnicamente poiché IronRuby è all'orizzonte, rSpec potrebbe essere un'opzione per coloro che sono pronti ad andare al limite. NBehave + NSpec potrebbe essere il framework più vecchio con la migliore automazione, anche se mi sono trovato a combattere contro la sintassi eccessivamente prolissa.

Li controllerei tutti e sceglierei il framework più adatto allo stile dei tuoi progetti. Sono tutti OSS, quindi è difficile da perdere, il vero vantaggio è semplicemente passare al BDD.

Answer 5

Personalmente consiglierei BDDfy che è fantastico secondo me! È open source, supporta la descrizione di scenari basati su convenzione e fluente, copre sia l'accettazione che i test unitari. Puoi trovarlo su GitHub .

Answer 6

Robot Framework può anche essere usato con IronPython per fare ATDD o BDD in .Net. Penso che le capacità di espressione di Robot Framework siano migliori di quelle es. SpecFlow o NSpec . Non ti obbliga a utilizzare una certa sintassi, ma utilizza invece un approccio basato su parole chiave. Se stai testando applicazioni web, ha Selenium2Library che fornisce collegamenti a Selenium WebDriver.

Answer 7

C'è anche Spettro , che definisce un DSL in Boo per renderlo tutto più naturale.

Answer 8

In genere andrei a favore di NBehave, combinato con MbUnit e qualsiasi framework DI / beffardo di cui hai bisogno. È un giusto commento di Jim Burger che NBehave è molto prolisso, e a volte mi ritrovo a usare il taglia e incolla. Tuttavia, funziona benissimo: sto usando il plug-in ReSharper di Gallio, quindi ho solo una finestra in più che mostra. Tuttavia, non l'ho ancora provato con ccnet.

Answer 9

Controlla questo post sul blog e i suoi commenti per idee stimolanti: http : //haacked.com/archive/2008/08/23/introducing-subspec.aspx/

Answer 10

Concordion.NET non supporta solo BDD ma anche ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd -bdd-ATDD / Le specifiche sono scritte in inglese semplice utilizzando HTML. IMHO questo è uno dei vantaggi di Concordion.NET. I documenti HTML possono essere organizzati in una struttura navigabile per creare un sistema di documentazione vivente . E, dal momento che i test vengono eseguiti sul sistema, puoi essere certo che la documentazione sia sempre aggiornata.

Answer 11

Sto iniziando la mia prima uscita in BDD con una piccola applicazione con il mio team. Gli strumenti che scegliamo di svolgere il lavoro sono: Specflow con Selenium Webdriver per xBehave storie e MSpec con Machine.Fakes.Moq per un container di automocking per i nostri test unitari xSpec. Con Resharper sia il nostro corridore di storia che il corridore di specifiche grazie all'integrazione supportata da Specflow e MSpec. Avere l'integrazione nativa in Visual Studio con R # è una caratteristica chiave per noi.

Dato che il nostro design è tutto MVC3, applicheremo anche modello di separazione dell'orchestrator ai nostri controller MVC . Questo ci consentirà di scrivere le specifiche direttamente contro l'orchestrator. Quindi per noi scrivere storie direttamente contro l'utilizzo delle nostre applicazioni.

Answer 12

Dato che ora sto trattando BDD per test di sistema per applicazioni critiche per la sicurezza, posso solo condividere la mia esperienza che non dovresti sottovalutare il potere di "test scritti in un linguaggio naturale" invece di " code " ;.

Ci siamo sempre concentrati sull'offrire un linguaggio di funzionalità, che chiunque possa comprendere senza alcun background tecnico o esperienza nella programmazione (vedere l'esempio dello specflow sopra) e lo abbiamo fatto bene. Oltre al fatto che non ho mai spiegato la sintassi a nessuno, tutti hanno immediatamente capito il significato di test, sviluppatore, manager e persino tester.

Eviterei in ogni modo un test scritto in un linguaggio di programmazione come gli esempi MSpec sopra. Se mi faccio vedere con un test come questo nell'ufficio di un manager, mi darà il calcio d'inizio. Ma è interessato a leggere i test basati sulla sintassi di Gherkin. Più ragazzi sono in grado di leggere e modificare i test, meglio è.

Ultimo ma non meno importante, quei test sono portabili su qualsiasi altro linguaggio di programmazione, qualsiasi altra piattaforma, qualsiasi altro strumento di automazione del test senza modifiche.

Ancora una volta, la risposta è ancora una volta:

Non preoccuparti dello strumento e delle sue stesse funzionalità, scegli uno strumento che ti consenta di passare facilmente a un altro strumento in qualsiasi momento senza perdere informazioni. Gli strumenti vanno e vengono, i miei test dovrebbero durare più a lungo. : -)

Posso raccomandare di usare SpecFlow. Hai pieno accesso alla libreria .Net completa e a tutte le sue funzionalità, i tuoi test rimangono portatili. Questo potrebbe darti un vantaggio rispetto a soluzioni totalmente portatili come Robot Framework, se non ti dispiace la portabilità. Tuttavia, è sempre possibile migliorare la stabilità e la portabilità di un sistema utilizzando diversi strumenti per lo sviluppo e il test. Quindi testare un software .Net con un approccio BDD basato su Python potrebbe essere una buona (o addirittura la migliore) idea in alcuni casi.

Tuttavia, SpecFlow ha dimostrato di essere stabile e antiproiettile nei test di tutti i giorni, inclusi i test di costruzione notturni, ecc. in progetti di medie dimensioni. Inoltre, si integra bene con Microsoft Unit Test Environment.

Answer 13

Dai un'occhiata anche a UBADDAS, specifico per UAT disponibile su

https://github.com/KernowCode/UBADDAS

con una spiegazione qui

http://kernowcode.wordpress.com/ (a giugno 2014)

Puoi scrivere un test come questo

[Test]
public void IWantToRegisterANewUser()
{
  var user = new User();
  ICustomer customer = new Customer();

  SoThat(MyBusinessValue.IncreaseCustomerBase)
    .As(user)
    .Given(customer.Register)
    .When(customer.Confirm_Registration)
    .Then(customer.Login);
}

e produce questo

I want to register a new user
  so that Increase customer base
       as user
    given Register customer
     when Confirm customer registration
     then Login customer