# wp-tests-config.php : ce que ce fichier de bootstrap charge avant vos tests

> Avant le premier test, un fichier discret prépare la base, les constantes et le cœur de WordPress. Voici ce qu'il fait réellement, ligne par ligne.

- Auteur : WordPress Développement
- Publié le : 2020-01-17
- Mis à jour le : 2020-01-17
- Catégorie : Tests
- URL : https://www.wpmoderne.fr/tests/wp-tests-config-php-bootstrap-phpunit-wordpress/

## L’essentiel

- Un fichier de configuration séparé du code testé
- Des constantes à définir avant tout chargement
- Une base dédiée, jamais celle du site

Trois lignes rouges dans le terminal, et pourtant aucun test n'a encore été écrit : `Error: wp-tests-config.php not found`. Ce message apparaît systématiquement pour un développeur qui découvre la suite de tests officielle de WordPress, avant même la première assertion. Il révèle une étape que la documentation évoque brièvement mais dont le fonctionnement mérite d'être détaillé.

Ce fichier n'est pas un détail d'installation : il conditionne tout ce qui suit. Sans lui, PHPUnit ne sait pas où trouver une base de données, quel préfixe de table utiliser, ni comment charger le cœur de WordPress dans un contexte isolé du site réel. Comprendre son rôle exact évite des heures de tâtonnement au moment de configurer une nouvelle machine ou un nouveau pipeline.

## Un fichier à part, jamais versionné avec les secrets

Le paquet officiel de tests, récupéré via le script `install-wp-tests.sh` fourni par le cœur de WordPress, place ce fichier dans un dossier temporaire dédié aux tests, distinct de l'installation WordPress classique. Il ressemble à `wp-config.php` mais ne partage jamais son contenu : il pointe vers une base de données séparée, souvent nommée avec un suffixe explicite comme `wordpress_test`, pour qu'aucune donnée réelle ne soit jamais menacée par une suite de tests.

Cette séparation n'est pas cosmétique. Chaque exécution de la suite vide et recrée les tables nécessaires. Un développeur qui pointerait ce fichier vers sa base de développement perdrait ses données de test manuel à la première commande `phpunit`. La convention veut donc que ce fichier reste local, ignoré par le contrôle de version, et régénéré à chaque nouvelle machine.

## Ce qui est chargé, dans l'ordre

> L'essentiel à retenir : Un fichier de configuration séparé du code testé ; Des constantes à définir avant tout chargement ; Une base dédiée, jamais celle du site

Avant qu'un seul test ne s'exécute, plusieurs étapes se déroulent dans un ordre précis :

- Définition des constantes de connexion à la base de test (`DB_NAME`, `DB_USER`, `DB_PASSWORD`, `DB_HOST`).
- Définition de `WP_TESTS_DOMAIN`, `WP_TESTS_EMAIL` et `WP_TESTS_TITLE`, qui simulent un site WordPress minimal.
- Inclusion du fichier `wp-settings.php` du cœur, qui déclenche le chargement complet de WordPress dans ce contexte de test.
- Activation d'une extension ou d'un thème précis si le fichier de bootstrap personnalisé (souvent nommé `bootstrap.php`) l'exige.

C'est cette dernière étape qui distingue un simple fichier de configuration d'un véritable point d'entrée pour vos propres tests : le fichier `bootstrap.php` de votre extension appelle la bibliothèque de tests WordPress, qui elle-même lit `wp-tests-config.php` pour savoir à quelle base se connecter et quel domaine simuler.

## Les constantes qui changent tout

Deux constantes méritent une attention particulière. `WP_TESTS_TABLE_PREFIX` permet de faire cohabiter, sur une même base MySQL, plusieurs suites de tests sans collision de tables. C'est utile lorsque plusieurs projets partagent un serveur de développement local. La seconde, `WP_PHP_BINARY`, indique quel exécutable PHP utiliser pour les tests qui déclenchent un sous-processus, par exemple certains tests liés à WP-Cron ou aux tâches planifiées.

Une erreur fréquente consiste à copier ce fichier d'un projet à l'autre sans adapter le préfixe de table. Deux suites de tests utilisant le même préfixe sur la même base finissent par se marcher dessus : les données créées par l'une contaminent les fixtures de l'autre, provoquant des échecs impossibles à reproduire isolément.

## Un exemple minimal fonctionnel

```
<?php
define( 'DB_NAME', 'wordpress_test' );
define( 'DB_USER', 'root' );
define( 'DB_PASSWORD', '' );
define( 'DB_HOST', '127.0.0.1' );

$table_prefix = 'wptests_';

define( 'WP_TESTS_DOMAIN', 'example.org' );
define( 'WP_TESTS_EMAIL', 'admin@example.org' );
define( 'WP_TESTS_TITLE', 'Site de test' );

define( 'WP_PHP_BINARY', 'php' );
```

Ce squelette suffit dans l'immense majorité des cas. Les extensions plus complexes y ajoutent parfois des constantes propres à leur propre configuration, par exemple pour désactiver un envoi d'e-mail réel ou pointer vers un dossier d'uploads temporaire.

## Pourquoi le comprendre change la façon de déboguer

Un test qui échoue avec un message évoquant une connexion refusée à la base de données pointe presque toujours vers ce fichier, ou vers l'absence du service MySQL attendu. Un test qui semble « oublier » des réglages entre deux exécutions pointe souvent vers un préfixe de table partagé avec un autre projet. Savoir lire ce fichier en quelques secondes permet de distinguer immédiatement un problème d'environnement d'un véritable bug applicatif, ce qui change radicalement le temps passé à chercher dans la mauvaise direction.

> Sur un nouveau poste de développement, la première chose à vérifier n'est jamais le code des tests eux-mêmes, mais ce fichier de configuration : neuf incidents sur dix viennent de là avant même la première assertion.

## En résumé

`wp-tests-config.php` joue un rôle d'aiguillage silencieux : il ne contient aucune logique de test, mais il détermine où et comment WordPress va démarrer avant que la moindre assertion ne soit évaluée. Le comprendre en détail, plutôt que de le copier-coller aveuglément d'un projet à l'autre, évite la majorité des erreurs de configuration rencontrées lors de la mise en place d'une suite de tests sur une nouvelle machine ou un nouveau serveur de continuous integration.