# Behat contre Codeception pour du BDD sur un projet WordPress d’agence

> Deux façons d'écrire des scénarios lisibles par un client non technique. L'une mise sur la pureté Gherkin, l'autre sur l'intégration native à wp-browser.

- Auteur : Clément Hadrot
- Publié le : 2021-09-14
- Mis à jour le : 2021-09-14
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/behat-contre-codeception-bdd-wordpress/

## L’essentiel

- Behat impose Gherkin pur, sans échappatoire
- Codeception avec wp-browser mutualise le BDD et les tests techniques
- Le choix dépend surtout de qui écrit les scénarios

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"
```

> L'essentiel à retenir : Behat impose Gherkin pur, sans échappatoire ; Codeception avec wp-browser mutualise le BDD et les tests techniques ; Le choix dépend surtout de qui écrit les scénarios

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.