Mise en œuvre des scénarios Outline Cucumber dans les frameworks BDD
Le développement piloté par le comportement (BDD) est une pratique de développement logiciel agile qui améliore la collaboration entre les parties prenantes et les développeurs en utilisant un langage simple, propre au domaine, pour décrire le comportement du système.
L’un des outils les plus puissants dans le BDD est Cucumber, qui permet de rédiger des spécifications claires. Il peut également être utilisé dans les tests, avec la plupart des langages de programmation courants, comme Java, Python ou C#, et peut être intégré à des frameworks d’interface utilisateur, tels que Selenium, ou être utilisé pour les tests d’API.
Les scénarios Outline font partie de la syntaxe Gherkin de Cucumber, utilisée pour écrire des spécifications exécutables. Contrairement aux scénarios classiques qui définissent un seul exemple concret, les scénarios Outline permettent de spécifier plusieurs exemples sous forme de tableau.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Différences entre un scénario et un scénario Outline
Les scénarios dans Cucumber représentent un cas de test écrit sous la forme de base given-when-then. Le langage Gherkin permet à ces scénarios de test d’être écrits en anglais simple (et dans d’autres langues) afin qu’ils soient facilement compris et même rédigés par des personnes non techniques. Les définitions de pas, qui représentent l’implémentation des étapes, sont créées dans des fichiers séparés.
Pour certaines fonctionnalités, il est pertinent de répéter le même scénario en utilisant des données de test différentes – c’est ce que l’on appelle généralement le test piloté par les données. Dans Cucumber, cela se fait à l’aide du Scenario Outline avec une table d’exemples contenant les jeux de données à utiliser. Chaque exemple est compté comme un test distinct.
Syntaxe du Scenario Outline dans Cucumber
Un projet Cucumber typique contient des fichiers de fonctionnalités, où les tests cucumber sont définis, et des fichiers de définitions de pas, avec les implémentations des étapes.
Un fichier de fonctionnalités doit représenter une spécification d’exigence, et les scénarios sont utilisés pour le tester. La syntaxe de base pour un scénario simple sous Cucumber est la suivante :
Scénario : Connexion invalide
Étant donné que je navigue jusqu’à la page de connexion
Lorsque j’entre des identifiants non valides
Alors je reçois un message d’erreur
Le scénario peut également contenir des variables, qui seront traitées comme telles dans la définition d’étape.
Scénario : Connexion invalide
Étant donné que je navigue jusqu’à la page de connexion
Lorsque j’entre le nom d’utilisateur test et le mot de passe invalid
Alors je reçois un message d’erreur : "Invalid login".
Les valeurs "test", "invalid" et "Invalid login" seront traitées comme des variables. Voyons maintenant ce qui se passe lorsque nous voulons essayer différentes combinaisons des variables fournies : nous pourrions nous retrouver avec plusieurs scénarios bêtement identiques hormis les valeurs de variables, ou utiliser le scenario outline, qui permet d’utiliser un tableau pour définir les différentes combinaisons de données :
Alors je reçois un message d’erreur : "<error message>".
Exemples :
| nom d’utilisateur | mot de passe | message d’erreur |
| test | invalid | Invalid login |
| test | | Veuillez saisir le mot de passe |
| | invalid | Veuillez saisir le nom d’utilisateur |
La combinaison des données s’écrit sous le mot-clé « Exemples », à l’intérieur d’un tableau. Les en-têtes du tableau sont les noms des variables, chaque ligne représentant une combinaison de données. Chaque exemple dans une fonctionnalité Cucumber sera considéré comme un cas de test individuel.
Table d’exemples vs tables de données
Les exemples et les tables de données peuvent sembler similaires, mais ils remplissent des fonctions différentes. La principale différence est que les exemples servent à mettre en place des scénarios pilotés par les données, tandis que les tables de données sont utilisées lorsque les étapes du scénario requièrent l’utilisation de plusieurs variables.
Une table de données peut être utilisée de cette façon :
Scénario : Connexion invalide
Étant donné que je navigue jusqu’à la page de connexion
Lorsque j’entre les identifiants
| nom d’utilisateur | mot de passe |
| test | invalid |
Alors je reçois un message d’erreur : "Invalid login".
ou comme ceci :
Scénario : Connexion invalide
Étant donné que je navigue vers la page de connexion
Quand je saisis les identifiants
| nom d'utilisateur | test |
| mot de passe | invalide |
Alors je reçois un message d’erreur : "Connexion invalide".
Les tableaux de données sont particulièrement utiles lorsque les étapes nécessitent plusieurs variables et ils sont plus lisibles que lorsque chaque valeur est écrite à l'intérieur de l'étape.
Utiliser les tableaux de données et les scénarios d'exemple
Les tableaux de données et les scénarios d’exemple peuvent également fonctionner ensemble. Le nom de la variable sera indiqué dans le tableau de données et ensuite réutilisé dans le tableau d’exemples.
Scénario d'exemple : Connexion invalide
Étant donné que je navigue vers la page de connexion
Quand je saisis les identifiants
| nom d'utilisateur | <nom d'utilisateur> |
| mot de passe | <mot de passe> |
Alors je reçois un message d’erreur : "<message d’erreur>".
Exemples :
| nom d'utilisateur | mot de passe | message d’erreur |
| test | invalide | Connexion invalide |
| test | | Veuillez saisir le mot de passe |
| | invalide | Veuillez saisir le nom d'utilisateur |
Avantages de l’utilisation des scénarios d’exemple
Les scénarios d’exemple peuvent être considérés comme un « modèle » de cas de test. En réalité, lorsqu’ils sont implémentés dans un cadre d'automatisation de tests, ils exécutent le même scénario avec différentes séries de données.
L’avantage est qu’il y a moins de lignes de Gherkin et moins de répétition. Cela signifie que lorsqu’un changement est nécessaire dans le scénario commun, il suffit de le modifier une seule fois et le changement sera appliqué à toutes les combinaisons de données de test.
Un autre bénéfice des scénarios d’exemple est qu’ils permettent une couverture accrue avec un minimum d’effort. Pour ajouter un nouveau test, il suffit d’ajouter une nouvelle ligne d’exemple.
Bonnes pratiques pour rédiger des scénarios d'exemple
- Intégrez des données réelles : l’équipe sera moins encline à négliger des cas limites ou des détails cachés lorsqu’elle utilise des cas d’usage en temps réel pour comprendre le comportement.
- Communiquez l’objectif en utilisant la terminologie métier afin que les parties prenantes techniques et non techniques de l’équipe se comprennent mieux.
- Expliquez votre intention plutôt que la manière dont elle sera mise en œuvre ; la description des étapes doit être peu technique et doit davantage se concentrer sur les fonctions du système que sur son fonctionnement.
- Ne gardez que l’essentiel : pour maintenir le scénario attrayant pour tous les participants, évitez de le surcharger avec des étapes non nécessaires.
À retenir
Améliorer la collaboration: La BDD améliore la collaboration entre les parties prenantes et les développeurs.
Langage simple: La BDD utilise un langage simple et spécifique au domaine pour décrire le comportement du système.
Pratique agile: La BDD est une pratique intégrée au développement logiciel agile.
Implication des parties prenantes: La BDD implique les parties prenantes dans la définition du comportement du système.
Description du comportement système: La BDD se concentre sur une description efficace du comportement du système.
Cucumber est un excellent outil de collaboration entre personnes non techniques, développeurs et testeurs. C’est un outil BDD qui fournit des spécifications écrites et peut être utilisé pour les tests. Plusieurs scénarios peuvent être rédigés pour illustrer diverses exigences.
Il est pertinent d’utiliser les scénarios d’exemple avec des jeux de valeurs distincts fournis via le tableau d’exemples lorsqu’il y a des situations où les scénarios partagent les mêmes étapes, mais nécessitent des valeurs différentes en entrée ou en sortie.
Abonnez-vous à la newsletter de The CTO Club pour plus d’analyses.
