Utilizzo di SpecFlow per test di regressione end-to-end

Question

Utilizziamo BDD e utilizzando SpecFlow per guidare il nostro sviluppo (ATDD).

Il nostro team di QA desidera definire i propri test di regressione end-to-end (in Gherkin/SpecFlow) e riutilizzare i passaggi che abbiamo già definito.

(Si prega di notare - So che questo non è un grande esempio, ma dovrebbe fornire dettagli sufficienti)

Un test può includere ..

1. Login
2. Ricerca di un prodotto
3. Selezionare un prodotto per acquistare
4. Creare un ordine
5. Selezionare l'opzione di consegna.
6. Invia l'ordine.
7. Annulla l'ordine.

Questo sarebbe suggerisce uno scenario come ..

Dato Sono entrato
quando faccio una ricerca per un prodotto
E Selezionare un prodotto da acquistare
E creo un ordine
E I Selezionare l'opzione di consegna
E inviare l'ordine
E annullare l'ordine
Quindi ?? !!

Che è chiaramente errato in quanto non controlliamo l'output ad ogni passaggio.

Quindi questo può essere risolti come una sequenza di scenari:

Scenario 1:
Premesso Sono entrato
quando faccio una ricerca per un prodotto
poi vedo un elenco di prodotti

Scenario 2:
Quando seleziono un prodotto da acquistare
allora posso creare un ordine

Scenario 3:
Quando creo l'ordine
E I Selezionare l'opzione di consegna
Allora posso inviare l'ordine

etc etc

Il problema principale di questo è che ci sembra alcun modo per specificare l'ordine/sequenza in cui vengono eseguiti gli scenari (una caratteristica di nUnit?). Perché ci sono delle dipendenze tra gli scenari (non sono impostati su un punto di partenza noto) devono essere eseguiti in sequenza.

Le mie domande sono:

a) stiamo cercando di montare un piolo quadrato in un buco rotondo ?!

b) Qualcuno sa se esiste un modo per utilizzare SpecFlow/Gherkin in questo modo?

c) O qualcuno sa quali alternative ci sono?

Grazie mille!

Answer 1

Direi che stai scrivendo i tuoi scenari sul livello di astrazione sbagliato. Ma questo dipende da cosa vuoi usarli;

Se si desidera scrivere script di prova, si è sulla buona strada ... ma sarà un incubo da mantenere in quanto, nel primo caso (script lungo) sarà molto fragile e il secondo caso (diversi scenari) devono garantire un certo ordine di esecuzione. Entrambi sono scoraggiati e considerati anti-schemi.

Suggerisco di unire i test ATDD che si stanno scrivendo e di parlare con il reparto test per ottenere il loro punto di vista sull'argomento e includere i casi di test necessari per garantire che il sistema sia stato accuratamente testato. Chi lo sa? Potresti persino imparare qualcosa gli uni dagli altri: P

E quando scrivi quelle "specifiche" (come preferisco chiamarle) le scrivi ad un livello più alto. Così, invece di scrivere:

Given I am logged in 
When I Search for a product 
    And I Select a product to buy 
    And I Create an order 
    And I Select delivery option 
    And I Submit the order 

si scrive qualcosa di simile

When I submit an order for product 'Canned beans' 

nel passo-definizioni dietro quel passo di eseguire tutto ciò che l'automazione (login, la navigazione alla pagina del prodotto, selezionare le opzioni di consegna, inviare l'ordine).

Tutto questo può essere letto in questi grandi articoli su come scrivere mantenibili test di automazione interfaccia utente:

• http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/
• http://elabs.se/blog/15-you-re-cuking-it-wrong
• http://www.marcusoft.net/2011/04/clean-up-your-stepsuse-page-objects-in.html
• http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf
• http://gojko.net/2010/01/05/bdd-in-net-with-cucumber-part-3-scenario-outlines-and-tabular-templates/
• http://chrismdp.github.com/2011/09/layers-of-abstraction-writing-great-cucumber-code/
• http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories.html
• http://mislav.uniqpath.com/2010/09/cuking-it-right/

Spero che questo aiuta