Disclaimer: Je regardais mes articles phares de mon blog et je suis retombé sur mon article de l’ATDD et notamment Behat, je me suis rendu compte qu’il avait déjà 11 ans 😱 !!!!!
Voilà pourquoi un petit update, ne ferait pas de mal autour des concepts d’ATDD/BDD, qui restent des concepts clés encore aujourd’hui dans le développement logiciel de qualité !
N’hésites pas à relire cette relique autour de Behat et l’ATDD en 2012 … mis à jour en 2016 💪 😎
Les Tests d’Acceptation : Une Clé de Voûte de l’ATDD et du BDD avec Behat
Lorsqu’il s’agit de garantir que les nouvelles fonctionnalités répondent précisément aux exigences des utilisateurs, les tests d’acceptation se révèlent être un outil indispensable. Mais que sont exactement les tests d’acceptation ? Ce sont des conditions que le logiciel doit satisfaire pour être accepté par un utilisateur, un client ou, dans notre cas, par un Product Owner. Ces tests sont souvent écrits sous forme de scénarios utilisateurs, qui guident le développement et valident le bon fonctionnement des fonctionnalités.
ATDD : Un Cadre Structuré pour les Tests
Dans la méthodologie ATDD (Acceptance Test-Driven Development), ces tests d’acceptation sont rédigés avant même que le code ne soit implémenté. C’est une pratique qui s’inscrit dans une démarche de développement guidée par les tests, une approche qui, je l’ai découvert, est fortement préconisée par des experts tels que Claude Aubry. Celui-ci suggère d’utiliser un modèle d’écriture éprouvé pour les Product Owners, dérivé d’une méthode utilisée par Cucumber, un outil logiciel bien connu dans les cercles de développement Python initialement.
Gherkin et BDD : Des Langages des Comportements
Alors que je me plongeais plus profondément dans la documentation, j’ai découvert que la syntaxe utilisée pour écrire ces tests est connue sous le nom de Gherkin. Cette notation est au cœur du BDD (Behavior-Driven Development), une technique de développement logiciel qui encourage la collaboration entre développeurs, QA et non-techniciens.
Given – When – Then
La rédaction des scénarios en Gherkin est une composante essentielle du Behavior-Driven Development (BDD), une méthode de développement logiciel qui met l’accent sur la collaboration entre les développeurs, les testeurs et les utilisateurs non techniques.
Le format Gherkin se distingue par sa simplicité et sa lisibilité, utilisant un langage naturel pour décrire le comportement et les attentes d’une fonctionnalité.
Chaque scénario Gherkin suit généralement une structure Given-When-Then :
« GIVEN (Étant donné) » un contexte initial,
« WHEN (Quand) » une action spécifique est entreprise,
« THEN (Alors) » un résultat attendu doit se produire.
Cette structure permet de créer des tests clairs et compréhensibles qui servent à la fois de documentation et de base pour les tests d’acceptation automatisés. En facilitant la communication entre les parties prenantes techniques et non techniques, les scénarios Gherkin aident à aligner le développement sur les besoins réels des utilisateurs et à garantir que le logiciel livré répond effectivement aux exigences métier.
Voici un exemple de code / scénario pour vous montrer la simplicité de rédaction en langage naturel pour vous les PO 😮
# Langage : Gherkin
# Exemple de scénario pour une fonctionnalité de connexion utilisateur
Fonctionnalité: Connexion utilisateur
En tant qu'utilisateur de l'application web
Je souhaite pouvoir me connecter
Afin d'accéder à mon espace personnel
Scénario: Connexion réussie avec des identifiants valides
GIVEN que je suis sur la page de connexion
WHEN je saisis mon nom d'utilisateur "user@example.com"
AND que je saisis mon mot de passe "Password123"
AND que je clique sur le bouton de connexion
THEN je devrais être redirigé vers mon espace personnel
Scénario: Échec de la connexion avec un mot de passe incorrect
GIVEN que je suis sur la page de connexion
WHEN je saisis mon nom d'utilisateur "user@example.com"
AND que je saisis un mot de passe incorrect "WrongPassword"
AND que je clique sur le bouton de connexion
THEN un message d'erreur "Identifiants invalides" devrait s'afficherCe morceau de code Gherkin décrit deux scénarios typiques pour une fonctionnalité de connexion : un scénario où l’utilisateur se connecte avec succès et un autre où la connexion échoue à cause d’un mot de passe incorrect. Chaque scénario suit la structure Given-When-Then (Étant donné-Quand-Alors) pour décrire clairement le contexte, l’action et le résultat attendu.
Les tableaux de données 🤯🤯
Dans l’exemple ci-dessous, le « Scenario Outline » permet de réutiliser le même scénario avec différentes combinaisons de noms d’utilisateur et de mots de passe. Les valeurs entre « <> » sont des paramètres qui seront remplacés par les données fournies dans le tableau « Exemples ». Ce type de scénario est particulièrement utile pour tester une fonctionnalité avec plusieurs ensembles de données sans avoir à réécrire le même scénario plusieurs fois. Ce qui est complètement « Mindf*ck » 😮😮😮
# Langage : Gherkin
# Exemple de scénario avec Scenario Outline pour tester la connexion utilisateur avec différentes données
Fonctionnalité: Connexion utilisateur avec plusieurs ensembles de données
En tant qu'utilisateur de l'application web
Je souhaite tester la connexion avec différents ensembles de données
Afin de vérifier le comportement de l'application avec des identifiants variés
Plan du Scénario: Connexion avec différents identifiants
Étant donné que je suis sur la page de connexion
Quand je saisis le nom d'utilisateur "<username>"
Et que je saisis le mot de passe "<password>"
Et que je clique sur le bouton de connexion
Alors le résultat devrait être "<outcome>"
Exemples:
| username | password | outcome |
| user@example.com | Password123 | redirection vers espace personnel |
| user@example.com | WrongPassword | message d'erreur "Identifiants invalides" |
| invalid@example.com | Password123 | message d'erreur "Identifiants invalides" |
Behat : L’Outil BDD pour PHP
C’est alors que Behat entre en scène, un outil BDD dédié au PHP. Inspiré par Cucumber, Behat utilise le langage Gherkin pour permettre aux développeurs d’écrire des tests clairs et compréhensibles. Ce qui distingue Behat, c’est sa compatibilité native avec PHP, en particulier avec le framework Symfony, grâce à un bundle dédié.
L’avantage de Behat sur les Autres Outils
Qu’est-ce qui fait de Behat un choix supérieur à d’autres outils comme RobotFramework ? Sa facilité d’intégration avec Symfony, sa syntaxe intuitive et la possibilité d’exécuter des tests directement depuis la console en font un choix de prédilection pour les développeurs PHP.
Test et Intégration
J’ai eu la chance au cours de ces dernières années et lorsque je travaillais avec des équipes PHP de travailler avec Behat, et je peux vous dire que c’était bien fluide.
Malgré tout, je ne suis pas aussi sûr qu’aujourd’hui ce soit toujours le meilleur outil de BDD en PHP, il me faudrait faire de nouveaux tests et analyser un peu plus en profondeur la concurrence en 2023.
Pour ceux qui souhaiteraient ce plonger dedans je vous recommande forcément la doc officielle qui est pas mal du tout pour le coup : https://docs.behat.org/en/latest/ !
Partage d’Expérience
Je vous tiendrai informés de mes découvertes. Entre-temps, si vous avez déjà utilisé Behat ou pratiqué l’ATDD, je serais ravi de lire vos retours en commentaire. Chaque partage d’expérience enrichit notre connaissance collective.
Retrouvez bientôt plus d’insights sur coffee-meeting, le blog dédié à l’agilité et à l’innovation dans le développement logiciel. 😉
❤️
0 Commentaire