Un client dans le secteur associatif nous a demandé, après plusieurs régressions passées inaperçues sur son parcours d’adhésion en ligne, de pouvoir « lire et valider » les scénarios de test avant chaque mise en production, sans avoir à ouvrir une ligne de code PHP. C’est la promesse du BDD (Behavior-Driven Development) : des scénarios écrits en langage presque naturel, au format Gherkin, que Behat et Codeception savent tous deux interpréter — mais avec des philosophies très différentes.
Après avoir testé les deux sur ce projet précis, la comparaison mérite d’être posée sur trois critères concrets : la lisibilité réelle pour un non-développeur, le coût de maintenance des scénarios, et l’intégration avec l’écosystème WordPress existant.
Behat : du Gherkin pur, sans détour
Behat est un framework BDD généraliste, sans lien natif avec WordPress. Chaque scénario est écrit en Gherkin, puis relié à du code PHP via des définitions d’étapes (« step definitions ») que l’équipe technique doit écrire elle-même :
Fonctionnalité: Adhésion en ligne
Scénario: Un visiteur adhère avec succès
Étant donné que je suis sur la page "Adhérer"
Quand je remplis le formulaire avec un e-mail valide
Et que je valide le paiement de test
Alors je vois le message "Bienvenue parmi nos adhérents"Cette pureté a un prix : Behat ne fournit aucune interaction WordPress prête à l’emploi. Naviguer, se connecter en tant qu’administrateur, ou vérifier un état en base demande d’écrire soi-même chaque définition d’étape avec Mink, sa bibliothèque de navigation web sous-jacente.
Codeception avec wp-browser : le BDD intégré à l’écosystème
Codeception, via l’extension wp-browser déjà largement utilisée pour les tests d’acceptation WordPress, propose un module Gherkin qui réutilise directement les actions déjà disponibles pour l’équipe technique (création de contenus via les factories, connexion administrateur, assertions sur la base) :
Feature: Adhésion en ligne
Scenario: Un visiteur adhère avec succès
Given I am on page "/adherer"
When I fill field "Email", "visiteur@example.test"
And I click "Valider l'adhésion"
Then I see "Bienvenue parmi nos adhérents"
And there is 1 row in the "wp_usermeta" table where "meta_key" is "statut_adhesion"
La dernière ligne illustre l’avantage principal : vérifier un état en base de données directement dans le scénario Gherkin, sans écrire de définition d’étape personnalisée, puisque wp-browser l’expose nativement.
Comparatif sur trois critères
| Critère | Behat | Codeception + wp-browser |
|---|---|---|
| Lisibilité du Gherkin | Très haute, syntaxe libre | Haute, mais certaines étapes restent techniques (accès table) |
| Coût des définitions d’étape | Élevé, tout est à écrire | Faible, largement réutilisé de wp-browser |
| Cohabitation avec les tests techniques existants | Nécessite un second outil en parallèle | Même configuration, mêmes modules |
Verdict argumenté
Sur ce projet associatif, Codeception avec wp-browser s’est imposé pour une raison précise : l’équipe technique utilisait déjà wp-browser pour ses tests d’acceptation classiques, et dupliquer la configuration pour Behat n’aurait apporté aucune valeur supplémentaire, seulement une deuxième pile d’outils à maintenir. La mutualisation des modules et des helpers a permis d’écrire les scénarios Gherkin en une fraction du temps qu’aurait demandé Behat depuis zéro.
Behat reste pertinent dans un contexte différent : une équipe qui travaille sur plusieurs technologies au-delà de WordPress, où la neutralité de Behat vis-à-vis du framework testé devient un vrai atout, ou une organisation qui a déjà investi massivement dans des définitions d’étape Behat réutilisables entre projets.
Le choix ne se tranche pas sur la qualité intrinsèque de l’outil, mais sur une question simple : qui écrira les définitions d’étape, et combien de temps l’équipe est-elle prête à y consacrer avant le premier scénario utile ?
Points de vigilance quel que soit le choix
- Un scénario Gherkin trop détaillé techniquement perd tout son intérêt pour un lecteur non technique — la relecture avec le client doit rester un critère de qualité du scénario, pas une formalité.
- Les scénarios BDD ne remplacent pas les tests unitaires PHPUnit sur la logique métier fine : ils valident des parcours complets, pas des cas limites internes.
- Un scénario BDD lent à s’exécuter (chaque étape ouvre un navigateur réel) doit rester réservé aux parcours critiques, pas à toute la surface fonctionnelle du site.
Pour aller plus loin
Le choix entre les deux outils gagne à être posé après, et non avant, la mise en place de la première suite de tests d’acceptation technique du projet : la configuration déjà existante pèse souvent plus lourd dans la décision que les qualités théoriques comparées de Behat et de Codeception.
