definizioni step Feature con ambito con SpecFlow?

StackOverflow https://stackoverflow.com/questions/2943625

  •  05-10-2019
  •  | 
  •  

Domanda

sto usando SpecFlow di fare qualche test in stile BDD. Alcune delle mie caratteristiche sono test dell'interfaccia utente, in modo da utilizzare WatiN. Alcuni non sono test dell'interfaccia utente, in modo che non lo fanno.

Al momento, ho un unico file StepDefinitions.cs, che copre tutte le mie caratteristiche. Ho un passo BeforeScenario che inizializza WatiN. Ciò significa che tutti i miei test start up di Internet Explorer, se hanno bisogno o no.

C'è un modo in SpecFlow per avere un particolare file caratteristica associata con un particolare insieme di definizioni passo? O sto avvicinando questo dal punto di vista sbagliato?

È stato utile?

Soluzione

C'è una semplice soluzione al vostro problema se si utilizzano i tag.

In primo tag che 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 la BeforeScenario vincolante con un attributo che indica il tag: 

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

Questo metodo BeforeScenario sarà poi chiamato solo per le funzioni che utilizzano WatiN.

Altri suggerimenti

Attualmente (in SpecFlow 1,3) step-definizioni sono globali e non possono essere scope a particolari caratteristiche.

Questo è voluta per avere lo stesso comportamento di cetriolo.

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 le definizioni scoping alle funzioni dovrebbero essere evitati. Personalmente non sono ancora del tutto convinto su questo ...

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

Check this out (nuova funzionalità di SpecFlow 1.4): https://github.com / TechTalk / SpecFlow / wiki / mirino-Binding

I originariamente ipotizzato che un file passo è stato associato ad un particolare file funzione. Una volta mi sono reso conto che questo non era vero che mi ha aiutato a migliorare tutti i file il mio codice SpecFlow e lungometraggi. La lingua dei miei file caratteristica è ora meno contesto dipendeva, che ha portato a definizioni step più riutilizzabili e meno duplicazione del codice. Ora organizzo i miei file step in base alle somiglianze generali e non in base al quale dispongono servono. Per quanto ne so non c'è modo di associare un passo con una caratteristica particolare, ma io non sono un esperto di SpecFlow in modo da non prendere la mia parola per esso.

Se ancora desidera associare i file passo con un particolare file di funzione, solo dare loro nomi simili. Non c'è bisogno che venga costretto a lavorare solo per questa funzione anche se il codice passo ha senso solo per questa funzione. Questo perché, anche se vi capita di creare un passaggio duplicato per una caratteristica diversa, rileverà questa come delle partite ambiguo. Il comportamento per le partite ambigue può essere specificato in un file App.config. Vedere http://cloud.github.com/downloads/techtalk/SpecFlow/ SpecFlow% 20Guide.pdf per maggiori dettagli circa i file app.config. Per impostazione predefinita, le partite ambigue vengono rilevati e segnalati come errore.

[modifica]: In realtà c'è un problema con il lavoro in questo modo (con file STEP associati a file funzione solo in mente). Il problema nasce quando si aggiunge o modifica un file .Feature e utilizzare la stessa formulazione che avete usato prima, e si dimentica di aggiungere un passaggio per questo, ma non si nota perché è già stato creato un passaggio per tale formulazione una volta prima , ed è stato scritto in modo sensibile al contesto. Anche io sono più convinto della utilità di non associare i file passo con i file di funzionalità. Non credo che la maggior parte dei clienti sarebbero molto bravo a scrivere le specifiche in modo autonomo contesto. Questo non è il modo in cui di solito scrivere o parlare o pensare.

soluzione per questo è di implementare Tag & Scoped rilegatura con lo scenario di prova, che è legato al Web o legato al Logic Controller / core nel codice.

E drill-down l'ambito per ogni scenario di una delle sotto menzionato Prima / Dopo l'esecuzione 

BeforeTestRunScenario 
    BeforeFeature
        BeforeScenario
            BeforeScenarioBlock
                BeforeStep
                AfterStep
            AfterScenarioBlock
        AfterScenario
    AfterFeature
AfterTestRunScenario

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

  

When I search for 'Barbados'

anziché

  

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

Implementando più assembly definizione passo, lo stesso scenario può eseguire attraverso interfacce differenti. Usiamo questo approccio al test di interfaccia utente, API, ecc utilizzando lo stesso scenario.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top