Caractéristiques du concombre : un aperçu

Introduction

Gherkin est un langage encore utilisé dans de nombreux frameworks d'automatisation de tests. Parfois c'est parce que le client nous demande de l'utiliser, parfois c'est parce que l'équipe décide de le faire.

Pour être honnête, ce n'était pas le coup de foudre pour moi. Personnellement, j'ai un assez long voyage avec Gherkin - de l'aimer au début, de détester la langue pendant un certain temps, puis de l'aimer à nouveau. Dans cet article, je présenterai les fonctionnalités les plus importantes de Cucumber ainsi que l'implémentation de Java.

Voici toutes les fonctionnalités de Cucumber couvertes dans cet article :

Fichier de fonctionnalités

Tout d'abord, qu'est-ce qu'un fichier de fonctionnalités ? Dans le monde technique, une approche non technique a été créée pour permettre aux personnes non techniques de coopérer avec l'équipe lors du développement d'une application. Le langage Gherkin a été créé comme une couche supplémentaire dans l'approche BDD. Les tests Gherkin sont situés dans les soi-disant fichiers de fonctionnalités qui sont collés avec le code (Java, Kotlin, C# etc.). Habituellement, Gherkin est très facile à utiliser et nécessite des connaissances minimales en programmation, mais certaines fonctionnalités nécessitent un certain codage.

Commençons par quelque chose de facile.

Scénario

Voici l'exemple le plus simple et le plus simple à utiliser du test du concombre :

 Fonctionnalité : Scénario

 Contexte : avant les scénarios de test
   Étant donné que j'exécute avant l'étape

 @Test
 Scénario : Scénario 
   Étant donné que j'utilise l'étape paramétrée du "Scénario 1"

Bloc de code 1. Scénario

Le bloc de code 1. contient quelques éléments à expliquer :

• Fonctionnalité : le titre du fichier de fonctionnalité
• Contexte : le mot-clé qui permet à l'utilisateur d'exécuter des étapes de test avant chaque scénario de test défini dans le fichier de fonctionnalité
• @Test : Balise qui indique au framework de test quel scénario de test doit être exécuté. "Test" est défini par l'utilisateur. Nous pouvons utiliser par exemple "@SmokeTest"
• Scénario : Nom du scénario de test

Les tests Gherkin utilisent les mots clés [Given, When, Then, But] avant chaque étape de test. Dans notre seule étape de test, à l'exception de l'étape Background, nous utilisons un paramètre dans lequel nous passons la valeur "Scenario 1".

Voyons maintenant à quoi ressemble le code Java collé :

 @Given("J'exécute avant l'étape")
public void iExecuteBeforeStep() {
   //quelques implémentations
}

@Given("J'utilise l'étape paramétrée de {string}")
public void iUseParametrizedStepOf(String p) {
   //quelques implémentations
}

Bloc de code 2. Implémentation du code Java du scénario

Aperçu du scénario

Faisons quelque chose de plus complexe :

 Fonctionnalité : aperçu du scénario

 @Test
 Aperçu du scénario : aperçu du scénario
   Étant donné que j'exécute l'étape avec "<paramètre1>" et "<paramètre2>"
 Exemples:
     | paramètre1 | paramètre2 |
     | paramètre1a | paramètre2a |
     | paramètre1b | paramètre2b |

Bloc de code 3. Aperçu du scénario

Cette fois, nous utiliserons le plan de scénario qui nous permet de répéter des scénarios de test avec différentes configurations de données de test. Le bloc de code 3. contient peu de choses à expliquer :

• Exemples : la matrice des données de test à utiliser par les scénarios de test. La première ligne est un en-tête avec les noms des paramètres.

Et l'implémentation Java :

 @Given("J'exécute l'étape avec {string} et {string}")
public void iRunStepWithAnd(String p1, String p2) {
   //quelques implémentations
}

Bloc de code 4. Implémentation Java du plan de scénario

Tableau de données

L'aperçu du scénario est très utile, mais que se passe-t-il si nous ne voulons pas répéter l'intégralité du scénario de test mais une seule étape de test ? Gherkin a un moyen de le faire et il s'appelle "Data Table".

 Fonctionnalité : Tableau de données

@Test
Scénario : Scénario de table de données
 Étant donné que je vérifie que la colonne contient la valeur attendue
 | nom_colonne | valeurattendue |
 | unNomColonne | someExpectedValue |

Bloc de code 5. Tableau de données

Le scénario avec tableau de données ne diffère pas beaucoup de l'aperçu du scénario. La seule chose est que nous ne mettons pas le mot clé "Exemples" avant le tableau.

L'implémentation Java semble un peu plus complexe que dans les cas précédents :

 @Given("Je vérifie que la colonne contient la valeur attendue")
public void iVerifyColumnValuesInTableUsingQueryFromFileOnSchema(DataTable dataTable) {
   List<Carte<String, String>> data = dataTable.asMaps();
   for (Map<String, String> form : data) {
       String columnName = form.get("columnName");
       Chaîne ExpectedResult = form.get("expectedValue");
       //quelques implémentations
       }
   }
}

Bloc de code 6. Implémentation Java de Data Table

Pour accéder aux données d'une table de données, nous créons une variable spéciale dataTable de type "DataTable". Toutes les données seront stockées dans la variable List.

Contexte du scénario

En utilisant le contexte du scénario, nous pouvons partager des données entre les étapes. Supposons que nous ayons un scénario en deux étapes dans lequel nous souhaitons transmettre la valeur "données" de l'étape 1 à l'étape 2 (bloc de code 7).

 @Test
Scénario : Contexte du scénario
 Étant donné que j'ai défini la valeur de contexte de scénario "data"
 Étant donné que j'utilise la valeur de contexte de scénario

Bloc de code 7. Contexte du scénario

Tout d'abord, nous devons créer une classe spéciale appelée ScenarioContext avec des fonctionnalités de contexte de scénario pour définir et obtenir des données (Code Block 8). Notre contexte de scénario est un HashMap avec une paire clé-valeur. Nous identifierons les valeurs par sa clé.

• scenarioContext() : HashMap de la paire clé-valeur
• setContext() : méthode clé-valeur pour stocker les données de contexte de scénario
• getContext() : méthode pour obtenir les données fournissant la clé

 classe publique ScénarioContext {

   private Map<String, Object> scenarioContext ;

   scénario publicContext(){
       scenarioContext = new HashMap<>();
   }

   public void setContext (clé de contexte, valeur d'objet) {
       scenarioContext.put(key.toString(), value);
   }

   objet public getContext (clé de contexte) {
       return scenarioContext.get(key.toString());
   }

}

public enum Contexte {
   IDENTIFIANT;
}

Bloc de code 8. Implémentation Java de la classe Scenario Context

Ayant cela, nous pouvons utiliser les méthodes mises en œuvre. À l'étape 1, nous définissons ensuite la valeur dans le contexte du scénario et à l'étape 2, nous obtenons la valeur (Bloc de code 9).

 ScenarioContext scenarioContext = new ScenarioContext();

@Given("J'ai défini la valeur de contexte de scénario {string}")
public void iSetScenarioContextValue (valeur de chaîne) {
   scénarioContext.setContext(Context.ID, valeur);
}

@Given("J'utilise la valeur du contexte du scénario")
public void iUseScenarioContextValue() {
   String sharedValue = scenarioContext.getContext(Context.ID).toString();
}

Bloc de code 9. Étapes du contexte du scénario

Types de données de concombre

Cucumber gère un nombre limité de types de données. Nous pouvons définir des chaînes, des entiers et des valeurs flottantes, mais dans le cas de valeurs booléennes, nous devons coder certaines solutions de contournement.

 @Test
Scénario : Scénario avec variables
 Étant donné que j'utilise la chaîne "string", int 1, float 1.1 et boolean "false"

Bloc de code 10. Types de données de concombre

Le code Java ressemblerait à ceci :

 @Given("J'utilise la chaîne {string}, int {int}, float {float} et boolean {string}")
public void iUseStringIntFloatAndBoolean(String var1, int var2, double var3, String var4) {
   booléen f = booléen.valueOf(var4);
   // du code
}

Bloc de code 11. Implémentation Java des types de données Cucumber

Expression régulière de concombre

Il s'agit d'une autre fonctionnalité fréquemment utilisée. Le bloc de code 12 montre un scénario en deux étapes qui ne diffèrent que par l'utilisation de différentes valeurs variables (var1 et var2). Il ne s'agit en fait que d'une seule étape, et dans le code Java (Code Block 13) nous définissons une seule méthode mais avec regex et un paramètre var.

 @Test
Scénario : Scénario d'expression régulière
 Étant donné que j'utilise la variable var1
 Étant donné que j'utilise la variable var2

Bloc de code 12. Expression régulière dans le concombre

 @Given("^J'utilise la variable (.*)")
public void examTimeTableInSummerSeason(String var) {
   si (var.equals("var1")){
       // du code
   }
   sinon si(var.equals("var2")){
       // du code
   }
}

Bloc de code 13. Implémentation Java de l'expression régulière Cucumber

Crochets de concombre

Dernier point mais non le moindre : les crochets à concombre.

Le bloc de code 14 présente les 4 crochets les plus importants :

• @Before : Exécute le code avant chaque scénario de test
• @After : Exécute le code après chaque scénario de test
• @BeforeStep : Exécute le code avant chaque étape de test
• @AfterStep : exécute le code après chaque étape de test

 @Avant de
public void avantScenario() {
   // du code
}

@Après
public void afterScenario() {
   //un peu de code
}

@BeforeStep
public void beforeStep() {
   //un peu de code
}

@AfterStep
public void afterStep() {
   //un peu de code
}

Bloc de code 14. Crochets à concombre

Sommaire

J'espère vous avoir convaincu d'utiliser Gherkin dans vos tests. Ces quelques fonctionnalités rendront vos tests plus lisibles et plus faciles à comprendre par des personnes non techniques. De plus, pour les nouveaux entrants, il sera plus facile de comprendre la logique métier et de réduire leur temps d'intégration.