Utilisation de SpecFlow pour les essais de régression de bout en bout

nous employons BDD et utilisons SpecFlow pour piloter notre développement (ATDD).

notre équipe D'AQ voudrait définir ses propres tests de régression de bout en bout (dans Gherkin/SpecFlow) et réutiliser les étapes que nous avons déjà définies.

(Veuillez noter que je sais que ce n'est pas un bon exemple mais il doit fournir suffisamment de détails)

Un test peut inclure..

  1. se Connecter
  2. Rechercher un produit
  3. Sélectionnez un produit à acheter
  4. Créer une commande
  5. Sélectionnez l'option de livraison.
  6. soumettre la commande.
  7. Annuler la commande.

ceci suggère un scénario comme celui-ci..

etant Donné que je suis connecté

Lorsque je Recherche un produit

Et je choisis un produit à acheter

Et je Créer un bon de commande

Et j'Sélectionnez l'option de livraison

Et j'ai envoyer la commande

Et Je Annulez la commande

Alors ??!!

ce qui est clairement faux car nous ne vérifions pas la sortie à chaque étape.

Donc ce être réglée comme une séquence de scénarios:

Scénario 1:

Étant donné que je suis connecté

Lorsque je Recherche un produit

Puis je vois une liste de produits

scénario 2:

Lorsque je sélectionne un produit pour acheter

Ensuite, je peux créer une commande

scénario 3:

Quand j'ai créer la commande

Et j'Sélectionnez l'option de livraison

Ensuite, je peux envoyer la commande

etc etc

le principal problème avec ceci est qu'il ne semble pas possible de spécifier l'ordre/la séquence dans laquelle les scénarios sont exécutés (une caractéristique de nUnit?). Parce qu'il y a des dépendances entre les scénarios (ils ne sont pas set à savoir le point de départ) elles doivent être exécutées dans l'ordre.

Mes questions sont:

a) essayons-nous d'insérer une cheville carrée dans un trou rond?!

b) quelqu'un sait-il s'il existe un moyen d'utiliser SpecFlow/Gherkin de cette façon?

c) ou quelqu'un sait-il quelles sont les solutions de rechange?

merci Beaucoup!

8
demandé sur Mark Chidlow 2011-12-13 16:36:07

1 réponses

je dirais que vous écrivez vos scénarios sur le mauvais niveau d'abstraction. Mais cela dépend de ce pour quoi vous voulez les utiliser;

Si vous voulez test d'écriture des scripts alors vous êtes sur la bonne voie... mais il va être un cauchemar à maintenir que, dans le premier cas (long script) sera très fragile et le deuxième cas (plusieurs scénarios) nécessité d'assurer un certain ordre d'exécution. Tous les deux sont découragés et considérés comme des motifs anti-patterns.

je suggérez que vous fusionniez les tests ATDD que vous écrivez et parlez au service des tests pour obtenir leur point de vue sur la question et inclure les cas de test dont ils ont besoin pour s'assurer que le système est testé en profondeur. Qui sait? Vous pourriez même apprendre quelque chose l'un de l'autre :P

et quand vous écrivez ces "spécifications" (comme je les appelle plutôt) vous les écrivez à un niveau supérieur. Donc au lieu d'écrire:

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

vous écrivez quelque chose comme

When I submit an order for product 'Canned beans'

Dans le étape-définitions derrière cette étape, vous effectuez Tout ce que l'automatisation (connexion, navigation sur la page du produit, Sélectionner les options de livraison, soumettre la commande).

tout cela peut être lu dans ces grands articles sur la façon d'écrire maintenable UI Automation tests:

j'espère que cela aide

11
répondu Marcus Hammarberg 2011-12-14 13:08:42