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..
- se Connecter
- Rechercher un produit
- Sélectionnez un produit à acheter
- Créer une commande
- Sélectionnez l'option de livraison.
- soumettre la commande.
- 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!
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:
- 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/
j'espère que cela aide