Definizioni di passaggi con ambito feature con SpecFlow?

Question

Sto utilizzando SpecFlow per eseguire alcuni test in stile BDD. Alcune delle mie funzionalità sono i test dell'interfaccia utente, quindi usano WatiN. Alcuni non sono test dell'interfaccia utente, quindi non lo fanno.

Al momento, ho un singolo file StepDefinitions.cs, che copre tutte le mie funzionalità. Ho un passo BeforeScenario che inizializza WatiN. Ciò significa che tutti i miei test avviano Internet Explorer, che ne abbiano bisogno o meno.

C'è qualche modo in SpecFlow per avere un particolare file di funzione associato a un particolare insieme di definizioni di passi? O mi sto avvicinando da un angolo sbagliato?

Answer 1

C'è una soluzione semplice al tuo problema se usi i tag.

primo tag si dispongono di file per indicare che una particolare caratteristica ha bisogno WatiN così:

Feature: Save Proportion Of Sample Pool Required 
    As an <User> 
    I want to <Configure size of the Sample required> 
    so that <I can advise the deployment team of resourcing requirments>. 

    @WatiN 
    Scenario: Save valid sample size mid range 
    Given the user enters 10 as sample size 
    When the user selects save 
    Then the value is stored 

E poi decorare vincolante la BeforeScenario con un attributo che indica il tag:

[BeforeScenario("WatiN")] 
public void BeforeScenario() 
{ 
    ... 
} 

Questo metodo BeforeScenario verrà quindi chiamato solo per le funzioni che utilizzano WatiN.

Answer 2

Originariamente supponevo che un file passo fosse associato a un particolare file di caratteristiche. Una volta capito che questo non era vero, mi ha aiutato a migliorare tutti i miei file di codice e funzionalità di SpecFlow. La lingua dei miei file di funzione è ora meno dipendente dal contesto, il che ha portato a definizioni di passaggi più riutilizzabili ea una minore duplicazione del codice. Ora organizzo i miei file passo in base alle somiglianze generali e non in base a quale funzione sono. Per quanto ne so non c'è modo di associare un passo a una particolare caratteristica, ma io non sono un esperto di SpecFlow quindi non credetemi.

Se si desidera associare i propri file di passaggio con un particolare file di funzionalità, è sufficiente assegnare loro nomi simili. Non è necessario che sia forzato a funzionare solo per quella funzionalità anche se il codice di passaggio ha senso solo per quella funzione. Questo perché anche se ti capita di creare un passaggio duplicato per una funzionalità diversa, questa verrà rilevata come una corrispondenza ambigua. Il comportamento per le corrispondenze ambigue può essere specificato in un file App.config. Vedi http://cloud.github.com/downloads/techtalk/SpecFlow/SpecFlow%20Guide.pdf per ulteriori dettagli sul file App.config. Per impostazione predefinita, le corrispondenze ambigue vengono rilevate e segnalate come errori.

[modifica]: In realtà c'è un problema con il funzionamento in questo modo (con i file di passaggio associati ai file di funzione solo nella tua mente). Il problema si presenta quando aggiungi o modifichi un file .feature e usi lo stesso testo che hai usato in precedenza, e ti dimentichi di aggiungere un passaggio, ma non lo noti perché hai già creato un passaggio per quella formulazione una volta prima ed è stato scritto in modo sensibile al contesto. Inoltre non sono più convinto dell'utilità di non associare i file passo con i file di funzione. Non penso che la maggior parte dei clienti sarebbe molto brava a scrivere le specifiche in modo indipendente dal contesto. Non è così che normalmente scriviamo, parliamo o pensiamo.

Answer 3

Attualmente (in SpecFlow 1.3) le definizioni dei passaggi sono globali e non possono essere esaminate con funzionalità particolari.

Questo è progettato per avere lo stesso comportamento di Cucumber.

ho chiesto la stessa domanda sul gruppo di cetriolo:

http://groups.google.com/group/cukes/browse_thread/thread/20cd7e1db0a4bdaf/fd668f7346984df9#fd668f7346984df9

La linea di base è, che il linguaggio definito da tutti i file funzione dovrebbe anche essere globale (un comportamento globale di tutta l'applicazione). Pertanto, è necessario evitare le definizioni degli ambiti per le funzionalità. Personalmente non sono ancora del tutto convinto di questo ...

Tuttavia il problema con l'avvio WatiN solo per gli scenari che hanno bisogno UI-integrazione può essere risolto in due modi diversi:

• Tag e contrassegnata con ganci: Puoi taggare i tuoi scenari (es. Con @web) e definire ina BeforeScenario-Hook che deve essere eseguito solo per gli scenari con un determinato tag (es. [BeforeScenario ("web")]).Vedi l'integrazione del selenio nel nostro esempio di BookShop: http://github.com/techtalk/SpecFlow-Examples/blob/master/ASP.NET-MVC/BookShop/BookShop.AcceptanceTests.Selenium/Support/SeleniumSupport.cs

• Spesso separiamo completamente gli scenari legati all'interfaccia utente e gli scenari associati a un'API programmatica (cioè controller, modello di visualizzazione ...) in diversi progetti. Abbiamo cercato di illustrarlo nel nostro esempio di BookShop: http://github.com/techtalk/SpecFlow-Examples/tree/master/ASP.NET-MVC/BookShop/.

Answer 4

check this out (nuova funzionalità di SpecFlow 1.4): https://github.com/techtalk/SpecFlow/wiki/Scoped-Bindings

Answer 5

Considera anche utilizzando DSL implementazione-agnostic con definizioni specifiche di implementazione passo. Ad esempio, utilizzare

When I search for 'Barbados'

invece di

`Quando digito 'Barbados' nel campo di ricerca e premere il pulsante di ricerca

Implementando multipla assiemi di definizione dei passi, lo stesso scenario può essere eseguito attraverso diverse interfacce. Usiamo questo approccio per testare UI, API, ecc. Usando lo stesso Scenario.

Answer 6

Soluzione per implementare i tag & Binding evidenziato con lo scenario di test correlato a Web o correlato alla logica Controller/Core nel codice.

E drill-down di applicazione per ogni scenario qualsiasi sotto riportate Prima/Dopo l'esecuzione

BeforeTestRunScenario 
    BeforeFeature 
     BeforeScenario 
      BeforeScenarioBlock 
       BeforeStep 
       AfterStep 
      AfterScenarioBlock 
     AfterScenario 
    AfterFeature 
AfterTestRunScenario