Développement piloté par les comportements - SpecFlow

SpecFlow est un projet open source. Le code source est hébergé sur GitHub. Les fichiers de fonctionnalités utilisés par SpecFlow pour stocker un critère d'acceptation des fonctionnalités (cas d'utilisation, user stories) dans votre application sont définis à l'aide de la syntaxe Gherkin.

Le format Gherkin a été introduit par Cucumber et est également utilisé par d'autres outils. Le langage Gherkin est maintenu en tant que projet sur GitHub -https://github.com/cucumber/gherkin

Éléments de fonctionnalité et SpecFlow

Les principales caractéristiques des éléments Feature sont:

  • L'élément de fonction fournit un en-tête pour le fichier de fonction. L'élément de fonctionnalité comprend le nom et une description de haut niveau de la fonctionnalité correspondante dans votre application.

    • SpecFlow génère une classe de test unitaire pour l'élément d'entité, avec le nom de classe dérivé du nom de l'entité.

    • SpecFlow génère des tests unitaires exécutables à partir des scénarios qui représentent des critères d'acceptation.

  • Un fichier d'entités peut contenir plusieurs scénarios utilisés pour décrire les tests d'acceptation de l'entité.

    • Les scénarios ont un nom et peuvent se composer de plusieurs étapes de scénario.

    • SpecFlow génère une méthode de test unitaire pour chaque scénario, avec le nom de la méthode dérivé du nom du scénario.

Plusieurs étapes de scénario

Les scénarios peuvent avoir plusieurs étapes de scénario. Il existe trois types d'étapes qui définissent les conditions préalables, les actions ou les étapes de vérification qui composent le test d'acceptation.

  • Les différents types d'étapes commencent soit par le Given, When ou Then les mots-clés respectivement et les étapes suivantes du même type peuvent être liées à l'aide du And et But mots clés.

  • La syntaxe Gherkin permet toute combinaison de ces trois types d'étapes, mais un scénario comporte généralement des blocs distincts de Given, When et Then déclarations.

  • Les étapes du scénario sont définies à l'aide de texte et peuvent avoir une table supplémentaire appelée DataTable ou un texte multiligne appelé arguments DocString.

  • Les étapes du scénario sont un moyen principal d'exécuter un code personnalisé pour automatiser l'application.

  • SpecFlow génère un appel dans la méthode de test unitaire pour chaque étape du scénario. L'appel est effectué par le runtime SpecFlow qui exécutera la définition d'étape correspondant à l'étape du scénario.

  • La correspondance est effectuée au moment de l'exécution, de sorte que les tests générés peuvent être compilés et exécutés même si la liaison n'est pas encore implémentée.

  • Vous pouvez inclure des tables et des arguments multilignes dans les étapes du scénario. Ceux-ci sont utilisés par les définitions d'étape et sont passés sous forme d'arguments de table ou de chaîne supplémentaires.

Mots clés

Les balises sont des marqueurs qui peuvent être attribués à des fonctionnalités et des scénarios. Attribuer une balise à une fonction équivaut à attribuer la balise à tous les scénarios du fichier d'entités. Un nom de balise avec un @ au début indique une balise.

  • S'il est pris en charge par l'infrastructure de test unitaire, SpecFlow génère des catégories à partir des balises.

  • Le nom de catégorie généré est le même que le nom de la balise, mais sans le signe @.

  • Vous pouvez filtrer et regrouper les tests à exécuter à l'aide de ces catégories de tests unitaires. Par exemple, vous pouvez baliser des tests cruciaux avec @important, puis exécuter ces tests plus fréquemment.

Éléments d'arrière-plan

L'élément de langage d'arrière-plan permet de spécifier une condition préalable commune pour tous les scénarios dans un fichier d'entités

  • La partie d'arrière-plan du fichier peut contenir une ou plusieurs étapes de scénario qui sont exécutées avant toutes les autres étapes des scénarios.

  • SpecFlow génère une méthode à partir des éléments d'arrière-plan qui est appelée à partir de tous les tests unitaires générés pour les scénarios.

Plans de scénario

Les contours de scénarios peuvent être utilisés pour définir des tests d'acceptation basés sur les données. Le plan de scénario se compose toujours d'une spécification de modèle de scénario (un scénario avec des espaces réservés de données utilisant la syntaxe <placeholder>) et un ensemble d'exemples qui fournissent des valeurs pour les espaces réservés

  • Si le framework de test unitaire le prend en charge, SpecFlow génère des tests basés sur des lignes à partir de plans de scénario.

  • Sinon, il génère une méthode logique de test unitaire paramétrée pour un aperçu de scénario et une méthode de test unitaire individuelle pour chaque ensemble d'exemples.

  • Pour une meilleure traçabilité, les noms de méthode de test unitaire générés sont dérivés du titre du plan de scénario et de la première valeur des exemples (première colonne du tableau des exemples).

  • Il est donc recommandé de choisir un paramètre unique et descriptif comme première colonne de l'ensemble d'exemples.

  • Comme la syntaxe Gherkin exige que toutes les colonnes d'exemple aient des espaces réservés correspondants dans l'aperçu du scénario, vous pouvez même introduire une colonne arbitraire dans les ensembles d'exemples utilisés pour nommer les tests avec plus de lisibilité.

  • SpecFlow effectue la substitution d'espace réservé en tant que phase distincte avant de faire correspondre les liaisons d'étape.

  • L'implémentation et les paramètres dans les liaisons d'étapes sont donc indépendants du fait qu'ils soient exécutés via un scénario direct ou un aperçu de scénario.

  • Cela vous permet de spécifier ultérieurement d'autres exemples dans les tests d'acceptation sans modifier les liaisons d'étape.

commentaires

Vous pouvez ajouter des lignes de commentaires aux fichiers d'entités à tout endroit en commençant la ligne par #. Attention cependant, car les commentaires dans votre spécification peuvent être le signe que les critères d'acceptation ont été mal spécifiés. SpecFlow ignore les lignes de commentaire.