Behat est un outil open source en PHP permettant d’écrire des tests automatisés dans un langage clair et littéraire.

Son objectif est simple : rendre les tests compréhensibles par tous les membres d’une équipe — développeurs, chefs de projet, QA, voire clients — sans nécessiter de compétences techniques avancées.

Cette approche améliore considérablement la communication au sein d’une équipe et favorise une meilleure compréhension du comportement attendu d’une application.

Retour sur les concepts de base de Behat, partagés lors de notre dernière réunion technique Webnet.

Présentation technique : Concepts de base de Behat

Les avantages de Behat

• Langage clair et lisible par tous

• Tests proches des cas d’usage réels

• Possibilité d’utiliser une base de données dédiée aux tests

• Favorise la qualité du code

• Réduction des régressions

Les inconvénients

• Coût plus élevé en entreprise (environ +20 à +30 % par ticket en moyenne)

• Exécution plus lente que des tests unitaires

Behat dans la pyramide des tests

Dans la pyramide des tests automatisés, Behat se situe au sommet : il s’agit de tests fonctionnels de type E2E (End-to-End).

Ces tests simulent des scénarios concrets d’utilisation de l’application.

Exemple concret

Contexte :
Je travaille sur une plateforme qui gère les livraisons d’un dépôt pour le compte de plusieurs sociétés vers des clients finaux.

Un scénario Behat pourrait être :

Je suis connecté en tant que Julien ayant le rôle Admin
Lorsque je crée un bon de commande de livraison pour la société Webnet
Alors un bon de commande de livraison avec le statut « new » est créé en base de données

Dans cet exemple, certains éléments peuvent être dynamiques (utilisateur, rôle, société, statut). Nous reviendrons sur cette notion plus bas.

La structure Given / When / Then

Behat repose sur la syntaxe Gherkin et la matrice :

• @Given

• @When

• @Then

@Given — Le contexte

Exemple :
« Je suis connecté en tant que Julien ayant le rôle Admin »

Il s’agit de l’état initial.
Toutes les phrases définissant un contexte commencent par @Given.

@When — L’action

Exemple :
« Je crée un bon de commande de livraison pour la société Webnet »

On déclenche ici une action métier.
Cela peut correspondre à :

• une action en interface utilisateur

• un appel API REST

• une requête GraphQL

• un envoi de payload

Toutes les actions commencent par @When.

@Then — La vérification

Exemple :
« Alors un bon de commande de livraison avec le statut new est créé en base de données »

On vérifie ici le résultat attendu.

Toutes les assertions commencent par @Then.

@And

Le tag @And permet d’enchaîner plusieurs phrases du même type (Given, When ou Then) sans répétition.

Structure d’un fichier Feature

Un fichier .feature contient :

Feature

Description textuelle de ce que l’on souhaite tester.
Elle n’a aucun impact technique sur l’exécution.

Background

Le Background contient les éléments communs à tous les scénarios.

Il est exécuté avant chaque scénario.

Exemple :
Si tous les scénarios nécessitent un utilisateur « Julien » connecté, on définit cela dans le Background plutôt que de le répéter.

Scenario

Un scénario est un cas de test indépendant.

Lorsqu’un scénario s’exécute :

1. Le Background est chargé

2. Le scénario s’exécute

3. Un rollback est effectué

4. Le scénario suivant démarre proprement

Les scénarios ne s’impactent donc pas entre eux.

Installation

Si vous travaillez sur un framework ou un CMS PHP, il est nécessaire de vérifier la compatibilité.

Pour Symfony, l’extension recommandée est :
https://github.com/FriendsOfBehat/SymfonyExtension

Fonctionnement technique : les Contexts

Behat repose sur des classes appelées Context.

Chaque classe doit :

• se terminer par Context

• implémenter l’interface Context fournie par Behat

Exemples :

• DeliveryContext

• JwtContext

• DatabaseContext

• FixtureContext

Ces classes regroupent les phrases et la logique métier associée.

Associer une phrase à une fonction

Chaque phrase Given / When / Then est reliée à une méthode PHP.

Exemple :

/**
* @When I create a delivery order for :company
*/
public function iCreateADeliveryOrderFor(string $company)
{
     ...
}

Variables dynamiques

Les variables dynamiques sont définies par :variable.

Elles deviennent automatiquement des paramètres de la fonction.

Plusieurs phrases pour une même méthode

Il est possible d’associer plusieurs annotations à une même méthode.

Dans ce cas, les paramètres supplémentaires doivent être déclarés nullable afin d’éviter les erreurs si une phrase plus courte est utilisée.

Hooks : BeforeScenario et AfterScenario

Behat propose également des hooks :

• @BeforeScenario

• @AfterScenario

Ces annotations permettent d’exécuter du code automatiquement avant ou après chaque scénario.

Exemple :

Si vous avez besoin de jeux de données (fixtures), vous pouvez créer un FixtureContext contenant une méthode annotée @BeforeScenario qui chargera ces données.

Ainsi, chaque scénario démarrera avec un environnement maîtrisé.

Tester le résultat final (@Then)

Deux approches sont possibles :

I – Lever une exception manuellement

if ($response->getStatusCode() !== 200) {
     throw new \Exception('Erreur');
}

II – Utiliser les assertions de PHPUnit

Behat fonctionne très bien avec PHPUnit, qui propose de nombreuses méthodes d’assertion :

• assertEquals

• assertInstanceOf

• assertTrue

• etc.

Souvent, la réponse précédente est stockée dans une propriété comme $this->response.

Écriture finale des scénarios

Une fois les Contexts prêts, vous pouvez écrire vos tests en langage naturel.

Les IDE modernes permettent :

• navigation automatique vers la méthode liée

• autocomplétion des phrases existantes

La puissance de la réutilisabilité

L’un des grands avantages de Behat est la création de briques réutilisables.

Exemple :

When I send the payload { … } for API request :apiPath

Cette phrase pourra être utilisée dans tous les scénarios testant un flux API REST ou GraphQL.

Cela permet :

• cohérence

• factorisation

• lisibilité

• réduction du code dupliqué

Conclusion

Behat est un outil puissant pour écrire des tests fonctionnels réalistes, compréhensibles et maintenables.

Il demande un investissement initial plus important que les tests unitaires, mais il apporte :

• meilleure communication

• documentation vivante

• réduction des régressions

• amélioration continue de la qualité logicielle

Dans des projets complexes ou orientés métier, il devient un véritable levier de qualité.