Sviluppo guidato dal comportamento - SpecFlow

SpecFlow è un progetto open source. Il codice sorgente è ospitato su GitHub. I file di funzionalità utilizzati da SpecFlow per memorizzare un criterio di accettazione per le funzionalità (casi d'uso, storie utente) nell'applicazione vengono definiti utilizzando la sintassi di Gherkin.

Il formato Gherkin è stato introdotto da Cucumber ed è utilizzato anche da altri strumenti. Il linguaggio Gherkin è mantenuto come progetto su GitHub -https://github.com/cucumber/gherkin

Elementi di funzionalità e SpecFlow

Le caratteristiche principali degli elementi Feature sono:

  • L'elemento feature fornisce un'intestazione per il file feature. L'elemento caratteristica include il nome e una descrizione di alto livello della caratteristica corrispondente nell'applicazione.

    • SpecFlow genera una classe di unit test per l'elemento feature, con il nome della classe derivato dal nome della feature.

    • SpecFlow genera unit test eseguibili dagli scenari che rappresentano i criteri di accettazione.

  • Un file di funzionalità può contenere più scenari utilizzati per descrivere i test di accettazione della funzionalità.

    • Gli scenari hanno un nome e possono essere costituiti da più passaggi dello scenario.

    • SpecFlow genera un metodo di unit test per ogni scenario, con il nome del metodo derivato dal nome dello scenario.

Passaggi multipli dello scenario

Gli scenari possono avere più passaggi dello scenario. Esistono tre tipi di passaggi che definiscono le condizioni preliminari, le azioni o le fasi di verifica che compongono il test di accettazione.

  • I diversi tipi di passaggi iniziano con il file Given, When o Then le parole chiave rispettivamente e i passaggi successivi dello stesso tipo possono essere collegati utilizzando il And e But parole chiave.

  • La sintassi Gherkin consente qualsiasi combinazione di questi tre tipi di passaggi, ma uno scenario di solito ha blocchi distinti di Given, When e Then dichiarazioni.

  • I passaggi dello scenario vengono definiti utilizzando il testo e possono avere una tabella aggiuntiva denominata DataTable o testo multilinea denominato DocString arguments.

  • I passaggi dello scenario sono un modo principale per eseguire qualsiasi codice personalizzato per automatizzare l'applicazione.

  • SpecFlow genera una chiamata all'interno del metodo di unit test per ogni passaggio dello scenario. La chiamata viene eseguita dal runtime SpecFlow che eseguirà la definizione del passaggio corrispondente al passaggio dello scenario.

  • La corrispondenza viene eseguita in fase di esecuzione, quindi i test generati possono essere compilati ed eseguiti anche se l'associazione non è ancora implementata.

  • È possibile includere tabelle e argomenti su più righe nei passaggi dello scenario. Questi vengono utilizzati dalle definizioni dei passaggi e vengono passati come tabelle aggiuntive o come argomenti di stringa.

Tag

I tag sono indicatori che possono essere assegnati a funzionalità e scenari. Assegnare un tag a una funzionalità equivale ad assegnare il tag a tutti gli scenari nel file di funzionalità. Un nome tag con una @ iniziale indica un tag.

  • Se supportato dal framework di unit test, SpecFlow genera categorie dai tag.

  • Il nome della categoria generata è uguale al nome del tag, ma senza il simbolo @ iniziale.

  • È possibile filtrare e raggruppare i test da eseguire utilizzando queste categorie di unit test. Ad esempio, puoi contrassegnare i test cruciali con @important, quindi eseguire questi test più frequentemente.

Elementi di sfondo

L'elemento della lingua in background consente di specificare una precondizione comune per tutti gli scenari in un file di funzionalità

  • La parte in background del file può contenere uno o più passaggi dello scenario che vengono eseguiti prima di qualsiasi altro passaggio degli scenari.

  • SpecFlow genera un metodo dagli elementi in background che viene richiamato da tutti gli unit test generati per gli scenari.

Contorni dello scenario

Gli schemi di scenario possono essere utilizzati per definire test di accettazione basati sui dati. La struttura dello scenario consiste sempre in una specifica del modello di scenario (uno scenario con segnaposto di dati che utilizzano la sintassi <placeholder>) e una serie di esempi che forniscono valori per i segnaposto

  • Se il framework di unit test lo supporta, SpecFlow genera test basati su righe dai contorni dello scenario.

  • In caso contrario, genera un metodo logico di unit test parametrizzato per una struttura dello scenario e un metodo di unit test individuale per ogni set di esempi.

  • Per una migliore tracciabilità, i nomi dei metodi di unit test generati sono derivati ​​dal titolo della struttura dello scenario e dal primo valore degli esempi (prima colonna della tabella degli esempi).

  • È quindi buona norma scegliere un parametro univoco e descrittivo come prima colonna nel set di esempi.

  • Poiché la sintassi di Gherkin richiede che tutte le colonne di esempio abbiano segnaposto corrispondenti nella struttura dello scenario, è anche possibile introdurre una colonna arbitraria nei set di esempio utilizzati per denominare i test con maggiore leggibilità.

  • SpecFlow esegue la sostituzione del segnaposto come una fase separata prima della corrispondenza delle associazioni di passaggio.

  • L'implementazione ei parametri nelle associazioni di fase sono quindi indipendenti dal fatto che vengano eseguiti tramite uno scenario diretto o uno schema di scenario.

  • Ciò consente di specificare in seguito ulteriori esempi nei test di accettazione senza modificare le associazioni dei passaggi.

Commenti

È possibile aggiungere righe di commento ai file delle caratteristiche in qualsiasi punto iniziando la riga con #. Fai attenzione, tuttavia, poiché i commenti nelle tue specifiche possono essere un segno che i criteri di accettazione sono stati specificati in modo errato. SpecFlow ignora le righe di commento.