2017-08-01 1 views
1

J'essaie de convertir le test de sélénium en cornichon. Est-il possible de mettre en œuvre des instructions si dans cornichons? Exemple: supposons que le code est écrit dans le format ci-dessous. Comme je ne peux pas coller le code réel, je suis en train d'écrire la description ci-dessous. S'il vous plaît comprendre la partie après une double barre oblique est le code de sélénium réelleComment mettre en œuvre «si» dans Gherkin

// launch the application 
// login to application 
// navigate to page 
String str; 
if(str== "XYZ") 
{ 
    // verify title 
} 
//verify text field 1 
//verify test field 2 
//verify select box 

Pour cela, je suis en train d'écrire du code dans Gherkin comme suit

Given user launches the application 
When user login with valid credentials 
and navigate to required page 
When String str is "XYZ" 
Then verify title 
And verify text field 1 
And verify test field 2 
And verify select box 

mais ce code est incorrect parce que si la str ne correspond pas à "XYZ" nous voulons que ce titre ne soit pas vérifié mais d'autres vérifications comme le champ "field1,2" et la case "select" doivent être vérifiées.

Quelqu'un peut-il aider?

+0

Réponse possible ici https://stackoverflow.com/questions/30233391/does-if-else-concept-available-in-feature-file-gherkin-language –

+0

Salut @DanielFintinariu, je suis passé par le lien mais j'ai besoin un moyen/une solution si possible sans scinder le scénario en deux scénarios de test –

+0

Selon le scénario, vous pouvez utiliser "Given-When-Then - steps". – Aby

Répondre

1

Vous pouvez écrire le scénario, un peu comme ceci:

Given the user launches the application 
When user login with valid credentials 
And navigates to required page 
Then he should see the page datails 

vous Dans l'étape Then gérer toute la logique.

Then(/^he should see the page datails$/) do 
    if condition 
    ... 
    else 
    ... 
    end 
end 
-2

vous devez créer strictement parler une déclaration alternatif le long des lignes de:

Given user launches the application When user login with valid credentials and navigate to required page When String str is NOT "XYZ"

+0

De cette façon ?? Compte tenu utilisateur lance l'application Lorsque l'utilisateur connexion avec les informations d'identification valides et accédez à la page requise Lorsque String str est « XYZ » Vérifiez ensuite le titre et vérifiez champ texte 1 et vérifiez champ de test 2 et vérifiez la boîte de sélection Lorsque La chaîne str n'est pas "XYZ" Vérifiez le champ de texte 1 Et vérifiez le champ de test 2 Et vérifiez le champ de sélection –

+0

Ce n'est pas du cornichon, vous êtes en train de coder en dur la syntaxe du cornichon avec les codes, et de l'appeler comme une méthode extérieure –

1

Idéalement, ce niveau de détail ne serait pas dans votre scénario cornichon. La meilleure approche consiste à décrire des cas d'utilisation commerciale, et non des détails de bas niveau. C'est pour cela que Gherkin est conçu pour: communiquer avec des parties prenantes non techniques afin que vous puissiez travailler si vous construisez la bonne chose en premier lieu. Voici ce que je voulais écrire:

Given the user is logged in 
And the user is on the required page 
When they enter data that requires the optional fields to be validated 
And they enter invalid data in the optional fields 
Then the form shows an error on the optional fields 

Les détails de bas niveau ne fait rien (que la chaîne est spécifiquement « XYZ » ou qu'il est le champ title est pas important), donc ceux-ci devraient être cachés dans les définition d'étape et/ou tests unitaires.

Afin de continuer à vérifier les autres champs, vous pouvez simplement ajouter une autre étape après:

When they enter invalid data in all of the other fields 
Then each other field has an error message attached to it. 

Encore une fois, il n'y a pas besoin de spécifier les champs réels, ou les séparer dans leurs propres étapes. L'idée est d'exprimer la valeur commerciale de haut niveau du scénario, c'est-à-dire que le formulaire est validé quand il devrait l'être. L'avantage de garder les choses de haut niveau est que lorsque le formulaire change (comme il le deviendra probablement), ce scénario peut rester intact. Ce qui est correct puisque l'analyse de rentabilisation est la même: elle devrait valider lorsqu'elle est supposée l'être. Tous les changements seront dans les définitions d'étape. Cela signifie qu'il n'y a aucune raison d'avoir une autre discussion avec vos parties prenantes pour savoir si vos scénarios testent toujours la bonne chose.

1

Gherkin n'est pas un langage de programmation à utiliser if ou else conditions. C'est une partie du cadre BDD, qui est mise en œuvre, pour que les parties prenantes et autres ressources non techniques comprennent le processus de test. Par conséquent, il est toujours recommandé, vous gardez le cornichon aussi simple et aussi générique que possible.

4

Vous n'implémentez pas dans Gherkin.Gherkin est sur la communication et ceux avec qui vous voulez communiquer, non codeurs, ne savent pas ce qu'est une instruction if. Ils ne s'en soucient pas non plus.

La solution? Deux scénarios pour couvrir les deux cas.