Archives par mot-clé : gherkin

Cas pratique d’écriture d’un test automatique en français

Source: https://www.pxfuel.com/en/free-photo-jepee

Dans mon précédent article sur les tests automatisés, je parlais d’écrire les tests en français. Je vous ai présenté un test et parlé de son anatomie. Vous connaissez maintenant la base de la syntaxe Gherkin.

Des outils comme Cucumber et Behat permettent d’interpréter les fichiers de fonctionnalité (feature) contenant les scénarii de test.

Terminologie

Avant d’aller plus loin, un petit point terminologie, nous réalisons ici des tests d’acceptation. Il est courant d’entendre parler de tests fonctionnels mais ce terme peut s’appliquer à d’autres types de test.

Voyons maintenant comment écrire le scénario pour tester la connexion d’un utilisateur sur notre application web.

Déterminer les cas d’usage de la fonctionnalité à tester

Nous allons donc tester la connexion d’un utilisateur. Quelles sont les différentes situations qu’un utilisateur peut rencontrer lors de la connexion ?

Le premier cas est une connexion réussie avec son identifiant et son mot de passe.

Le deuxième cas est une connexion échouée en raison d’un mauvais mot de passe.

Le troisième cas est une connexion échouée en raison d’un identifiant inconnu.

Et c’est tout. Notre application n’utilise pas de double authentification et ne dispose pas de la mémorisation de l’utilisateur (remember me).

Déterminer les pré-requis, l’état initial du test

Maintenant que nous avons tous les cas de figure métier de la connexion d’un utilisateur, quel doit être l’état du système avant de commencer un cas de test ?

Le premier pré-requis est que nous devons ouvrir un navigateur Internet et charger la page de connexion d’un utilisateur sur notre application web.

Le second est qu’un utilisateur doit être présent en base de données pour permettre la réalisation de deux des scénarii.

Et c’est tout.

Déterminer ce qui sera vérifié

Maintenant, qu’allons-nous vérifier ?

Dans le cas d’une connexion réussie, nous devons arriver sur la page du compte de l’utilisateur.

Dans le cas d’une connexion échouée, nous devons être sur la page de connexion et le message « Identifiant ou mot de passe invalide ».

Pour des raisons de sécurité, la distinction entre un compte inconnu et un mot de passe erroné n’est pas affichée.

Écrire les scénarii

Maintenant, nous pouvons passer à l’écriture d’un fichier de fonctionnalité (feature).

#language fr
Fonctionnalité: Connexion d'un utilisateur

  Contexte:
    Etant donné que l'utilisateur "test" est enregistré avec le mot de passe "test123456!"
    Et que je suis sur la page de connexion

  Scénario: Connexion réussie
    Lorsque je me connecte en tant que "test" avec le mot de passe "test123456!"
    Et que je valide la connexion de l'utilisateur
    Alors je dois être sur la page du compte de l'utilisateur "test"

  Plan du Scénario: Identifiant incorrect
    Lorsque je me connecte en tant que "<identifiant>" avec le mot de passe "<mot_de_passe>"
    Alors je dois être sur la page de connexion
    Et le message d'erreur "Identifiant ou mot de passe incorrect" est visible

  Exemples:
    | identifiant | mot_de_passe |
    | test        | abracadabra  |
    | toto        | abracadabra  |

Avez-vous remarqué que j’ai regroupé les deux scénarii d’échec ? C’est une fonctionnalité de la syntaxe Gherkin. Il est possible de jouer plusieurs fois le même scénario avec des informations différentes.

Explication du fichier

Mais revenons au début du fichier. Si vous comparez avec ce que je vous ai montré dans mon précédent article, il y a beaucoup de chose en plus !

Contexte

A la ligne 1, nous trouvons la définition de la langue utilisée dans le fichier.

A la ligne 2, le terme « Fonctionnalité: » est un mot clé Gherkin qui lui indique le début du test d’une fonctionnalité. Le texte qui suit le mot clé est un commentaire (il peut être sur plusieurs lignes).

A la ligne 4, le terme « Contexte » indique que les phrases (ou étapes) qui suivent (ligne 5 et 6) doivent être réalisées avant chaque scénario de la fonctionnalité. Le contexte est très utile pour alléger les scénarii. Cela permet de disposer le système dans un état donné commun à toute la fonctionnalité.

Scénario simple

Le premier scénario débute à la ligne 6 et ressemble plus à ce dont j’ai parlé dans le précédent article.

Cependant, il y deux points que je souhaite vous montrer :

Les textes entre guillemets est celui qui sera saisi sur la page de connexion par l’outil de tests. Il est possible de récupérer ainsi des informations depuis les phrases permettant leur réutilisation.

A la ligne 10 (comme à la ligne 6 et 16), la phrase commence par le mot clé « Et que » (ou « Et »). Ce mot clé est utilisé en remplacement des autres mots clés pour éviter la répétition et obtenir un texte compréhensible.

Plan de scénario

A la ligne 13 nous découvrons le mot clé « Plan du Scénario ». Celui-ci indique à l’outil qu’il doit exécuter le scénario plusieurs fois en fonction d’un tableau de données.

Dans les phrases du plan, les éléments qui changent entre chaque exécution sont placés entre les signes « inférieur » et « supérieur ». Le texte présent entre ces deux signes désigne le nom de la colonne où trouver la donnée.

Les données en elles-mêmes sont présentées sou forme de tableau après le mot clé « Exemples » (ligne 18 et suivantes).

Récapitulons

Dans cet article, nous avons vu comment analyser une fonctionnalité et écrire un fichier de scénario contenant tous les cas que nous souhaitons tester.

Nous avons également découvert quelques mots clés supplémentaires nous permettant d’écrire des scénarii simples et concis.

La simplicité des phrases et la concision des tests permet à tous les intervenants de comprendre facilement et rapidement le fonctionnement de l’application.

Cadeau

Après avoir bien travaillé, je vous offre un cadeau. En plus d’avoir écrit un test qui sera exécuté avant chaque livraison de votre application, nous venons d’écrire de la documentation.

Oui, les tests d’acceptation (comme les autres d’ailleurs) font partie de la documentation de votre application.

La documentation fournie par les tests a la particularité d’être maintenue à jour. Il serait dommage de s’en priver.

Intéressé par le sujet ?

Merci d’avoir lu jusqu’à la fin ! Contactez-moi pour en discuter et restez connecté !