Affrontare multipli, leggere variazioni in Speciflow

Question

Ciao tutti Stiamo sviluppando un servizio web che sarà disponibile tramite sapone e riposo (XML e JSON).Le nostre funzionalità di Speciflow sono per lo più uguali, cioè:

Scenario: There are at least 3 radio Channels 
Given The test server is up and running 
And The previously obtained channel list is reset
When I request a list of radio channels
Then the resulting deliveryPackage contains a list of  at least 3 items

.

Tutte queste funzionalità devono essere testate per l'interfaccia SOAP, per l'interfaccia di riposo / XML e per l'interfaccia di riposo / json.

In Cetriolo, è possibile eseguire le funzionalità usando -r per dettare dove si trovano i file di passaggi, tuttavia in Speciflow, non ho ancora trovato un modo attorno ai file dei passaggi, in modo che possa avere la stessa funzione di funzionamentodiversi passaggi.

Preferirei non dover scrivere ogni scenario 3 volte per modificare l'implementazione del passo da utilizzare.

Allora, due domande: 1) Come eseguire una funzione 3 volte per 3 diverse interfacce che si aspettano gli stessi scenari identici? 2) Come posso scegliere il file passo corretto ogni volta?

La risoluzione (1) probabilmente risolverà (2).

Answer 1

Una miniera di collega ci ha dato una soluzione di funzionamento del pozzo: i contorni dello scenario:

Scenario Outline: Channels on different protocols
Given The test server is up and running
And The previously obtained channel list is reset
When I request a list of radio channels for the <protocol> and <binding>
Then the resulting deliveryPackage contains a list of  at least 3 items
Scenarios: 
| protocol | binding                          |
| XML      | BasicHttpBinding_IProgramService |
| JSON     | BasicHttpBinding_IProgramService |
| SOAP     | CustomBinding_IProgramService    |

.

Dietro le quinte, il test custodia è una funzione che riceve due parametri, uno per e uno per il.

L'esecuzione di questo scenario produce 3 test unitario, che è quello che stavo dopo.

Maggiori informazioni qui: Gestione gruppi di scenari correlati

Answer 2

L'unica cosa che mi viene in mente è l'utilizzo dello schema dello scenario che consente di definire una famiglia di scenari e quindi eseguire variazioni di esso fornendo diversi parametri in una tabella.

Ma non sono sicuro che questo sia giustificato l'uso del contorno dello scenario che è per lo più per indirizzare le variazioni di input, non in configurazione dell'infrastruttura.

Un'altra domanda se SPECFLOW è un posto giusto per configurare tali passaggi, non dovrebbero essere testati questi dettagli su un livello diverso (test di integrazione dell'infrastruttura e test unit per componenti), quindi Gherkin viene utilizzato solo per l'uso end-to-endTest di accettazione del caso.Qualche tempo fa avrei comodato che SpecFlow è uno strumento sbagliato per tali test, ma vedo che Gherkin è usato con successo a tutti i livelli, quindi forse la tua domanda aumenta di come si può adottare il tipo di chiusura (e cetriolo) per abilitare questo tipodi test senza codice ripetizione.

Answer 3

Specifico presenta un concetto chiamato tagging.Puoi decorare un passo con un tag.

Sfortunatamente, avrai ancora bisogno dello scenario in primo piano tre volte, ma con diversi @tags.

Si è quindi impostato il StepScopeAttribute sul metodo o sulla classe per dire che questo metodo / classe viene ammesso a una particolare caratteristica / scenario / tag.C'è un progetto di esempio qui dall'autore:

https://github.com/techtalk/specflow/tree/Master / Test / FeatureTests / ScopedSteps

Answer 4

Che ne dici di dire:

When I request a list of radio channels for JSON, XML and SOAP
Then the corresponding resulting deliveryPackages contains a list of  at least 3 items

.

Ogni definizione del passo può includere le tre interfacce separate.

Tuttavia, vorrei mettere in discussione se il tuo approccio è saggio.Supponendo che le interfacce separate condividano la stessa logica aziendale, è in realtà probabile che solo uno dei tre avrebbe fallito?Forse sarebbe stato meglio testare un piccolo numero di metodi chiave in tutte le interfacce e per la maggior parte dei metodi scegli solo un'interfaccia da testare contro?