Contrairement aux tests unitaires ou d’intégration, un test d’acceptation ne s’intéresse pas au code : il rejoue un parcours tel qu’un visiteur le vivrait, clics compris. Pour un site e-commerce qui vendait des abonnements, l’équipe avait un test manuel répété à chaque déploiement : « créer un compte, ajouter un abonnement au panier, payer en carte de test, vérifier l’e-mail de confirmation ». Automatiser ce scénario avec wp-browser a fait passer cette vérification de quinze minutes à moins d’une minute, exécutée à chaque build.
wp-browser est une extension de Codeception pensée spécifiquement pour WordPress : elle ajoute des modules qui savent parler à une base WordPress (WPDb), piloter un navigateur avec le contexte WordPress (WPWebDriver), et manipuler l’installation directement en PHP (WPLoader). Voici comment mettre en place le premier scénario.
Installer wp-browser et générer la structure de projet
L’installation se fait via Composer, en développement uniquement :
composer require --dev lucatume/wp-browser
vendor/bin/codecept init wpbrowser
L’assistant interactif demande l’URL du site de test, les identifiants de base de données et le chemin vers l’installation WordPress. Il génère ensuite trois suites : unit, functional et acceptance, chacune avec son fichier .suite.yml. C’est la suite acceptance qui nous intéresse ici.
Configurer WPWebDriver et WPDb
Le fichier acceptance.suite.yml déclare les modules utilisés pendant les tests d’acceptation :
actor: AcceptanceTester
modules:
enabled:
- WPDb
- WPWebDriver
config:
WPDb:
dsn: 'mysql:host=127.0.0.1;dbname=wordpress_test'
user: 'root'
password: 'root'
dump: 'tests/_data/dump.sql'
populate: true
cleanup: true
url: 'http://wordpress.test'
WPWebDriver:
url: 'http://wordpress.test'
browser: chrome
host: localhost
port: 4444
window_size: 1280x1024
WPDb recharge un dump SQL avant chaque test (populate: true) et nettoie après (cleanup: true), ce qui garantit que chaque scénario démarre dans un état connu, sans dépendre de l’ordre d’exécution. WPWebDriver pilote un vrai navigateur via Selenium ou un conteneur Chrome headless, exactement comme le ferait un visiteur.
Écrire le premier scénario
Un test d’acceptation Codeception s’écrit en méthodes fluides, très proches du langage courant :
public function un_visiteur_peut_sabonner( AcceptanceTester $I ) {
$I->amOnPage( '/inscription/' );
$I->fillField( 'user_login', 'nouveau_client' );
$I->fillField( 'user_email', 'client@example.test' );
$I->fillField( 'user_pass', 'MotDePasse!42' );
$I->click( "S'inscrire" );
$I->see( 'Compte créé' );
$I->seeInDatabase( 'wp_users', array( 'user_login' => 'nouveau_client' ) );
}
La méthode seeInDatabase() vient du module WPDb : elle permet de vérifier l’état réel des tables WordPress après l’interaction, pas seulement ce qui s’affiche à l’écran. C’est la combinaison des deux modules qui rend wp-browser particulièrement adapté à WordPress plutôt qu’à un framework générique.
Utiliser les fabriques WPDb pour préparer un contexte
Plutôt que de cliquer à travers toute l’interface d’administration pour créer du contenu de test, WPDb expose des méthodes de fabrique directement en base :
$I->havePostInDatabase(['post_title' => 'Abonnement annuel', 'post_type' => 'product'])$I->haveUserInDatabase('redactrice', 'editor')$I->haveOptionInDatabase('woocommerce_currency', 'EUR')
Cela permet de garder le scénario d’acceptation concentré sur le parcours à valider, sans polluer le test avec la création manuelle de tout le contexte préalable.
Exécuter et diagnostiquer les échecs
La commande vendor/bin/codecept run acceptance lance la suite. En cas d’échec, Codeception enregistre automatiquement une capture d’écran et le HTML de la page dans tests/_output/, ce qui évite de relancer le test en mode debug pour comprendre ce qui a bloqué le navigateur. Sur des scénarios avec plusieurs étapes de formulaire, cette capture reste le moyen le plus rapide de repérer un sélecteur devenu invalide après une mise à jour de thème.
Pour aller plus loin
Ce premier scénario couvre l’essentiel : navigateur réel, base réinitialisée, assertions en base de données. Les alternatives basées sur Node, comme Puppeteer ou Playwright, répondent à un besoin différent et ne remplacent pas cette approche intégrée à l’écosystème PHP de WordPress — elles feront l’objet d’un article séparé.
