« Pourquoi ce test de vérification d’un simple libellé de statut met-il plus d’une seconde à s’exécuter ? » La réponse, une fois creusée sur un projet de gestion de réservations pour des salles de coworking, tenait en une ligne : la méthode setUp() de la classe de test créait systématiquement quinze réservations, huit utilisateurs et trois espaces, hérités d’un jeu de données conçu à l’origine pour un seul test de calcul de disponibilité, puis jamais réduit par la suite.
Ce schéma se répète dans beaucoup de suites de tests WordPress : une fixture globale, pratique au départ pour éviter de répéter du code de préparation, finit par grossir au fil des besoins de chaque nouveau test, sans que personne ne retire jamais ce qui devient superflu pour les tests plus anciens.
Le symptôme d’une fixture trop large
Un test qui vérifie qu’un libellé de statut s’affiche correctement n’a besoin que d’une seule réservation, avec un seul statut défini. Lorsque la méthode setUp() commune en crée quinze pour satisfaire les besoins d’un autre test de disponibilité, ce test de libellé paie le coût de création de quatorze objets qu’il n’utilisera jamais, à chaque exécution.
Créer à la demande, dans chaque méthode
La correction ne consiste pas à supprimer la fixture partagée, mais à déplacer la création d’objets dans chaque méthode de test qui en a réellement besoin, en utilisant les factories WordPress pour rester concis :
public function ilAfficheLeLibelleReserveePourUneReservationConfirmee(): void
{
$reservation_id = self::factory()->post->create([
'post_type' => 'reservation_salle',
'meta_input' => ['statut_reservation' => 'confirmee'],
]);
$libelle = wpm_libelle_statut_reservation($reservation_id);
$this->assertSame('Réservée', $libelle);
}
public function ilCalculeCorrectementLaDisponibiliteAvecPlusieursReservations(): void
{
$espace_id = self::factory()->post->create(['post_type' => 'espace_coworking']);
foreach (range(1, 4) as $i) {
self::factory()->post->create([
'post_type' => 'reservation_salle',
'meta_input' => ['espace_id' => $espace_id, 'statut_reservation' => 'confirmee'],
]);
}
$this->assertSame(4, wpm_compter_reservations_actives($espace_id));
}
Le premier test crée un unique objet, le second en crée quatre, chacun adapté strictement à ce qu’il vérifie. Aucun des deux ne dépend d’un état préparé ailleurs, ce qui rend également chaque test lisible indépendamment des autres, sans avoir à remonter jusqu’à une méthode setUp() partagée pour comprendre le contexte.
Le cas des données réellement communes
Certaines données restent légitimement partagées, comme un rôle personnalisé enregistré une seule fois pour toute la suite, ou une taxonomie déclarée globalement. La règle qui distingue ce qui reste dans setUp() de ce qui migre vers chaque méthode : une donnée reste commune si elle configure l’environnement WordPress lui-même, elle migre si elle constitue un cas de test métier particulier.
Ce que ce changement a produit sur ce projet
Après réorganisation de l’ensemble des fixtures selon ce principe, le temps moyen d’exécution des tests de la classe concernée a chuté de 4,2 secondes en moyenne par test, principalement grâce à la réduction du nombre d’écritures en base pour les tests qui n’en avaient pas besoin. L’effet secondaire, tout aussi précieux : chaque test est devenu compréhensible seul, sans devoir remonter au début du fichier pour savoir quelles données existent déjà.
- Repérer les tests dont le temps d’exécution dépasse nettement la moyenne de la suite.
- Identifier, pour chacun, la part des données créées en
setUp()réellement utilisée par ce test précis. - Déplacer la création des données non partagées directement dans la méthode de test concernée.
- Vérifier que la suppression d’une donnée de
setUp()ne fait échouer aucun autre test qui en dépendait silencieusement.
Une fixture qui sert à tout le monde finit par ne servir personne correctement.
En résumé
Réduire chaque fixture au strict nécessaire pour le test qui la consomme rend une suite à la fois plus rapide et plus lisible, sans nécessiter d’outil supplémentaire : les factories WordPress standard suffisent, à condition de résister à la facilité d’une fixture globale surdimensionnée. Sur ce projet de coworking, ce seul changement a réduit significativement le temps moyen d’exécution des tests unitaires les plus simples.
