Traiter avec plusieurs, de légères variations dans SpecFlow

Question

Salut à tous Nous développons un service web qui seront disponibles par le biais de SAVON et de REPOS (xml et JSon).Notre specflow caractéristiques sont essentiellement les mêmes, j'.e:

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

Toutes ces caractéristiques doivent être testés pour l'interface SOAP, pour le REST/Xml de l'interface, et pour le REST/JSon interface.

Pour le concombre, il est possible d'exécuter les fonctions utilisant l'option-R de dicter les cas où les mesures sont situés les fichiers, mais dans SpecFlow, je n'ai pas encore trouvé un moyen de contourner les mesures de fichiers, de sorte que je puisse avoir la même fonction d'exécuter les différentes étapes.

Je préfère ne pas avoir à écrire chaque scénario 3 fois pour changer l'étape de la mise en œuvre d'utilisation.

Donc, deux questions:1) Comment puis-je exécuter une fonction 3 fois pour 3 interfaces différentes qui attendent exactement les mêmes scénarios?2) Comment puis-je choisir la bonne étape fichier à chaque fois?

La résolution de (1) sera probablement résoudre (2).

Answer 1

Un collègue de mienne nous a donné une solution de travail bien de travail: scénario décrit:

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    |

Dans les coulisses, le boîtier de test est une fonction qui reçoit deux paramètres, un pour et un pour le.

Exécution de ce scénario produit 3 tests unitaires, ce que j'étais après.

Plus d'infos ici: Gestion des groupes de scénarios connexes

Answer 2

La seule chose qui me vient à l'esprit consiste à utiliser le contour des scénarios permettant de définir une famille de scénarios, puis d'exécuter des variations de celui-ci en fournissant des paramètres différents dans une table.

Mais je ne suis pas sûr que cela soit justifié l'utilisation du contour des scénarios qui consiste principalement à cibler les variations d'entrée, pas dans la configuration de l'infrastructure.

Une autre question si SPECFLOW est un endroit idéal pour configurer de telles étapes, ces détails ne doivent pas être testés à un niveau différent (tests d'intégration de l'infrastructure et tests d'unité pour les composants), donc le gherkin n'est utilisé que pour une utilisation finale à la fin.test d'acceptation de cas.Il y a quelque temps, j'irais insister que Specflow est un mauvais outil pour de tels tests, mais je vois que Gherkin est utilisé avec succès à tous les niveaux, alors votre question soulève peut-être un bon point de savoir comment Specflow (et Gherkin) peut être adopté pour permettre ce type.des tests sans répétition de code.

Answer 3

SpecFlow dispose d'un concept de marquage.Vous pouvez décorer une étape avec une balise.

Malheureusement, vous aurez encore besoin du scénario présenté trois fois, mais avec différents @balises.

Puis, vous définissez la StepScopeAttribute sur la méthode ou classe de dire que cette méthode/classe est limitée à une fonctionnalité particulière/scénario/tag.Il est un exemple de projet de l'auteur:

https://github.com/techtalk/SpecFlow/tree/master/Tests/FeatureTests/ScopedSteps

Answer 4

Du 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

Chaque définition étape peut inclure les trois interfaces distinctes.

Cependant, je voudrais poser des questions si votre approche est sage.En supposant que les interfaces distinctes partagent la même logique commerciale, est-ce qu'il s'agit probablement que l'un des trois échoue?Serait peut-être préférable de tester un petit nombre de méthodes clés sur toutes les interfaces et que la majorité des méthodes choisissent simplement une interface à tester?