Cornichon - il suffit de ré-utilisation des déclarations que Lorsque les déclarations... acceptable?

Question

Voici trois exemples de BDD états qui devrait aider à expliquer à ma question:

Scenario: User logs in
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
Then I should see the login successful page

Scenario: User buys a product
Given I am logged into the system using username "myUsername" and "myPassword"
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory

vs

Scenario: User buys a product
Given I am on the login screen
And I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory

Donc, le scénario 1 est très bien, mais qui est le meilleur de la déclaration 2 et 3.Déclaration 2 lit agréablement et de façon plus concise.Mais mon étape de définition pour "Étant donné que je suis connecté au système en utilisant le nom d'utilisateur "myUsername" et "monmotdepasse"" devrez répéter les appels à la Page des Objets (ou équivalent) que le scénario 1 appelé...semble plus dev effort.

Donc vraiment me demandais si quelqu'un sait de qui est la meilleure pratique.J'ai cherché en ligne et a trouvé le document suivant:http://docs.behat.org/guides/1.gherkin.html

Cette suggestions scénario 2 est le meilleur, mais écrit ensuite:"Authentifier un utilisateur (Une exception à la non-interaction recommandation.Des choses qui “est arrivé plus tôt” sont ok)", ce qui peu se prête pour le scénario 3.

Cheers,

Charlie

Answer 1

Voici mon examen des scénarios que vous avez écrites.

Scénario 1

Scenario: User logs in
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
Then I should see the login successful page

avantages : Vous utilisez correctement les déclarations données, quand, puis des déclarations. Dans ce scénario, l'état initial définit l'état initial du système, le moment indique les actions qu'un utilisateur prendra et que les affirmations détaillent ensuite pour vérifier le comportement du système.

contre : tandis que ce que vous avez écrit fonctionnera, le problème que vous avez est que ce test est fragile. Si votre entreprise devait guider qu'un jeton de sécurité dépendant de temps devait également être spécifié lors de la connexion (par exemple), vous devez ajouter une autre étape pour saisir ce champ supplémentaire. Cependant, si vous réécrivez cette étape pour être déclarative par exemple.

Given I am on the login screen
When I submit valid log-in criteria
Then I should see the login successful page

Ensuite, si le processus de connexion a été modifié, il suffirait de modifier le code, le scénario resterait le même.

Scénario 2

Scenario: User buys a product
Given I am logged into the system using username "myUsername" and "myPassword"
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory

avantages : comme ci-dessus.

contre : à nouveau, le test est fragile car il est impératif, c'est-à-dire que vous spécifiez les informations de connexion exactes et un produit spécifique. J'écrirais cela comme suit:

Given I am logged into the system
When I purchase a product
Then I should have that product in the product inventory

Vous pouvez enregistrer le produit spécifié dans le "quand" étape dans scénariocontext.current < / a>. Vous seriez alors en mesure de réutiliser cette valeur dans votre «puis» pour affirmer qu'il est présent dans l'inventaire du produit.

Scénario 3

Scenario: User buys a product
Given I am on the login screen
And I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory

contre : C'est le pire de vos scénarios que vous utilisez de manière incorrecte à l'instruction donnée. Une instruction donnée doit être utilisée pour définir un état système initial pour le test, de sorte que, dans ce cas, "étant donné que je suis sur l'écran de connexion" est une utilisation correcte, mais "donnée je saisi le nom d'utilisateur valide" MyAusername "" est une utilisation incorrecte . Il est incorrect car il indique une action de l'utilisateur, il devrait donc être couvert par un lorsque. Oui, vous pouvez utiliser une donnée pour effectuer les mêmes étapes programmatiques que lorsque, mais cela ne le rend pas correct!

Je changerais ce scénario à la version que j'ai suggérée dans le scénario 2.

Answer 2

Tout d'abord, il n'y a absolument rien de Cornichon qui vous empêche de rédaction du cahier des charges dans n'importe quel ordre, vous pouvez même produire des composés spécifications telles que

Given ...
When... 
Then ...
When ...
Then ...
Given ...
When ... 
Then ...

Alors, pourquoi voudriez-vous faire cela?

Eh bien d'abord, laisse envisager une quatrième variante de votre scénario

Scenario: User logs in and buys a product
  Given I am on the login screen
  When I enter the valid username "myUsername"
  And I enter the valid password "myPassword"
  And I press the login button
  Then I should see the login successful page
  When I purchase the product "myProduct"
  Then I should have "myProduct" in the product inventory

Ce n'est évidemment qu'un composé de 1 et de 2.Vous avez écrit, c'est parce qu'on a fini les tests de connexion et je voulais écrire rapidement et de tester l'achat d'un produit.Vous avez déjà le code de la Bindings dans le scénario de l'un et maintenant tout simplement besoin d'écrire les liaisons pour les deux scénarios.Vous pouvez considérer ceci comme votre plus simple, pragmatique changement, et vous permettra de refactoriser le code plus tard.Ce rien de mal à cela, exécuter les tests pourrait être plus rapide, mais également de son qui n'est pas idéal.

Maintenant, imaginez que, en raison de la nature de votre boutique, vous avez écrit de nombreux tests de tester les différents processus d'achat.Nous avons pu tester ce qui se passe quand vous ajoutez la même élément nouveau à votre panier, ou si vous essayez d'acheter quelque chose de rupture de stock ou différents caisse d'expériences si vous souhaitez une livraison spéciale.En fait, votre boutique est tellement réussie que vous avez besoin pour être vraiment en sécurité sur le web et modifier votre processus de connexion.Malheureusement, vous avez maintenant ces trois lignes

Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"

répété tout au long de vos scénarios.Si nous casser accidentellement notre processus de connexion avec certains mauvais code, tout à coup, toutes nos tests échouent.Vous êtes présenté avec un mur de rouge et ne peut pas vraiment étroites vers le bas par où commencer à chercher les problèmes.Parce que nous sommes dépendants de l'exploitation forestière en avant notre scénario, nous ne peut pas isoler la connexion à partir de l'achat.

C'est vraiment la différence entre un Given et un When.Un When il est là pour indiquer que nous sommes à l'exécution d'un processus, d'un Given est un moyen de toucher directement le temps d'exécution de l'environnement, de sorte que nous avons tout simplement d'avoir le bon état.C'est en gros la différence entre

//Given
isLoggedIn = true

//When
if CheckValidPasswordForUser(user, password)
   isLoggedIn = true

L' Given n'a aucun moyen d'échouer.

Donc, à venir tout le chemin du retour à votre question de départ,

Pouvez-vous ré-utiliser Givens comme Whens? Oui, mais dans le long terme, il va vous confondre.

Mais si vous demandez à Pouvez-vous ré-utiliser Whens comme Givens? alors je serais certainement vous conseiller de ne pas.Cela permet de masquer le fait que quelque chose qui pourrait briser est en train d'être testé.

Enfin, il y a une autre chose à considérer, et c'est le domaine de votre cahier des charges.Dan Nord a un très bon article sur ce Dont le Domaine est-il de toute façon?, mais l'essentiel appliquée à votre exemple, ici, c'est que lorsque vous êtes à la recherche à l'achat de produits, vous pouvez simplement écrire

Given I am logged in as a customer

ou

Given I am logged in as an administrator

car le nom d'utilisateur et le mot de passe pièces avec login et pas de produits, et de cette façon, vous êtes protégé contre la ré-écriture de tous vos scénarios lorsque vous modifiez votre processus de connexion à utiliser quelque chose d'autre.