Sono interessato a Behavior Driven Development (BDD)Quali strumenti/framework per lo sviluppo comportamentale (BDD) sono disponibili per Microsoft Stack?
Esistono buone strutture e/o strumenti disponibili per la piattaforma .Net (preferibilmente C# e ASP.Net)?
E quando BDD si è dimostrato più appropriato da utilizzare negli scenari del mondo reale? (domanda ausiliaria)
Su Google ho trovato Behavior Driven Development (BDD) with SpecFlow and ASP.NET MVC. Potresti trovarlo utile, dai un'occhiata. passare anche attraverso Behavior-Driven Development with SpecFlow and WatiN
Una bella presentazione su Pros and Cons of BDD
Un canale 9 Video Behavior-Driven Development in the Real World
e, ultimo ma non meno importante un articolo InfoQ Behavior Driven Development In .NET
anche MSpec è un buon quadro.
Lo uso nello stack Microsoft menzionato (C#, ASP.Net e MVC) e mi piace la sua sintassi.
BDD ti aiuta a pensare in modo aziendale/orientato alle funzionalità non solo in modo codice. Quindi sei più concentrato sul valore aziendale.
Aiuta anche nel test di accettazione degli utenti per creare un rapporto di fiducia tra voi e il cliente.
C'è un ottimo strumento, chiamato SpecFlow. SpecFlow è ispirato a Cucumber, il noto framework BDD per Ruby on Rails. E ha una grande quantità di vantaggi.
Si consiglia di controllare.
Parlamene, per favore. –
+1 per le raccomandazioni della gente su SpecFlow per gli scenari; mai usato, ma ho sentito molte cose positive su di esso. Ho usato semplicemente NUnit con una piccola DSL come this. MSTest avrebbe funzionato allo stesso modo.
È possibile fare anche BDD nello spazio unitario, che è ciò che MSpec è progettato per fare. Personalmente odio MSpec, ma il resto della squadra qui lo adora. A loro piace scrivere esempi di come funziona il codice. Mi piace mostrare perché il comportamento è prezioso. È una sottile distinzione e se non sei preoccupato di farlo a livello di unità non ti colpirà.
Altri framework da considerare includono Concordion, Fitnesse.NET (si prega di inserire FitSharp dietro di esso!) E TickSpec.
Nel mondo reale, il bit più prezioso di BDD è il numero di conversazioni , non i test automatici. Ecco un paio di suggerimenti rapidi e suggerimenti per farlo funzionare:
Non scrivere test automatizzati sulle cose che sono in continuo mutamento. Ti impegna solo a cose che hai sbagliato. Aspetta che l'interfaccia utente si sia sistemata un po ', poi fallo.
Se non ti interessa molto dell'interfaccia utente, ma ti preoccupi dell'integrità dei dati, scrivi gli scenari sul livello controller/presentatore (ad esempio: per le schermate di amministrazione).
Non iniziare con il login. Inizia descrivendo una parte preziosa dell'applicazione per cui è possibile accedere. Esegui prima ciò (supponi di avere un solo utente). Riceverai un feedback più rapido sui bit rischiosi.
Cercare un feedback rapido sui bit rischiosi, che di solito sono i bit che non hai mai fatto prima. Usa scenari per avere conversazioni intorno a loro. Scrivi qualcosa di interessante che scopri, ma dimentica gli scenari che sono ovvi: sono ovvi! Non preoccuparti di automatizzarli per iniziare. Avere conversazioni è più importante che scrivere le conversazioni è più importante che automatizzare le conversazioni.
Buona fortuna! Se vuoi saperne di più su BDD, ho messo insieme una pagina di link rilevanti here.
Questo è un po 'più come quello che stavo cercando. +1 –
Un interessante framework BDD è Concordion.NET. È un framework BDD open source per lo stack Microsoft che utilizza NUnit per eseguire i test di Concordion.NET: https://github.com/concordion/concordion-net Poiché le specifiche di Concordion sono scritte in HTML semplice, forniscono una buona base per un sistema di documentazione vivente. È possibile utilizzare un editor what-you-see-is-what-you-get (WYSIWYG) come BlueGriffon per descrivere il comportamento previsto del software in documenti HTML semplici e programmarli per verificare il sistema in prova. Secondo lo excellent classification of BDD tools, Concordion.NET si concentra su input leggibili dal business (e raggiunge anche l'output leggibile dal business). Si muove anche oltre BDD e supporta ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/
Spec4Net (https://bitbucket.org/fthomsen/spec4net/) è anche un buon framework. Lo usiamo ampiamente al lavoro. La curva di apprendimento è quasi inesistente e il flusso naturale sembra intuitivo.
LightBDD è un framework open source che consente di scrivere test BDD facili da leggere ma anche facili da mantenere ed estendere quando il progetto aumenta.
Le principali caratteristiche che offre sono:
Si basa su test scritti esclusivamente in codice, che significa supporto nativo per refactoring, analisi del codice, esecuzione di test e tutte le altre funzionalità offerte da Visual Studio/Intellisense/Resharper.
Un test esempio scritto in questo quadro si presenta come segue:
[TestFixture]
[FeatureDescription(
@"In order to access personal data
As an user
I want to login into system")] //feature description
[Label("Story-1")]
public partial class Login_feature //feature name
{
[Test]
[Label("Ticket-1")]
public void Successful_login() //scenario name
{
Runner.RunScenario(
Given_user_is_about_to_login, //steps
Given_user_entered_valid_login,
Given_user_entered_valid_password,
When_user_clicked_login_button,
Then_login_is_successful,
Then_welcome_message_is_returned_containing_user_name);
}
}
Maggiori informazioni su quadro potrebbe essere trovato sulla project wiki page e project main page.
Grazie mille Haris, ma chiunque può Google e restituire i collegamenti degli articoli. Spero di sentire alcune esperienze professionali degli sviluppatori e ciò che sanno di questi framework.Se ne sai di più su SpecFlow, ti prego di farmelo sapere. –
Non posso raccomandare abbastanza SpecFlow e WatiN, una combinazione geniale! –