« Préparez votre fixture dans le setUp, puis vérifiez avec une assertion, avant de nettoyer dans le teardown. » Cette phrase, parfaitement claire pour un développeur expérimenté, reste souvent opaque pour qui découvre les tests automatisés sur WordPress. Les termes s’empilent, empruntés à l’anglais, sans qu’aucune ressource ne prenne le temps de les définir un par un avec un exemple concret.
Pourtant, une fois ces quatre notions comprises, la structure de n’importe quelle classe de test PHPUnit devient lisible d’un seul coup d’œil, quel que soit le projet ou l’extension WordPress concernée. Ce texte les définit précisément, avec un exemple ancré dans un contexte WordPress plutôt que dans l’abstrait.
Fixture : l’état préparé avant le test
Une fixture désigne l’ensemble des données et de l’état nécessaires pour qu’un test puisse s’exécuter dans des conditions connues et reproductibles. Ce n’est pas un simple tableau de valeurs : c’est tout ce qui doit exister avant que le code testé ne soit appelé, un article en base, un utilisateur avec un rôle précis, une option activée.
public function test_seul_un_administrateur_peut_publier(): void {
// Ceci est la fixture : un utilisateur avec un rôle précis, déjà en base
$utilisateur_id = self::factory()->user->create( [ 'role' => 'editor' ] );
wp_set_current_user( $utilisateur_id );
$peut_publier = current_user_can( 'publish_posts' );
$this->assertTrue( $peut_publier );
}
Dans cet exemple, la fixture, c’est l’utilisateur créé avec le rôle editor et défini comme utilisateur courant. Sans cette préparation, la vérification qui suit n’aurait aucun sens : on ne peut pas tester une capacité de rôle sans qu’un utilisateur, avec ce rôle, existe réellement au moment du test.
setUp : la méthode qui construit la fixture avant chaque test
class PublicationTest extends WP_UnitTestCase {
private int $utilisateur_id;
protected function setUp(): void {
parent::setUp();
$this->utilisateur_id = self::factory()->user->create( [ 'role' => 'editor' ] );
}
public function test_peut_publier(): void {
wp_set_current_user( $this->utilisateur_id );
$this->assertTrue( current_user_can( 'publish_posts' ) );
}
public function test_peut_modifier_ses_propres_articles(): void {
wp_set_current_user( $this->utilisateur_id );
$this->assertTrue( current_user_can( 'edit_posts' ) );
}
}
setUp s’exécute automatiquement avant chaque méthode de test de la classe, sans qu’il soit nécessaire de l’appeler explicitement. Les deux tests de cet exemple bénéficient chacun d’un utilisateur fraîchement créé, sans jamais partager le même identifiant entre les deux exécutions : chaque test reçoit sa propre fixture, isolée des autres.
tearDown : le nettoyage après chaque test
protected function tearDown(): void {
wp_set_current_user( 0 );
parent::tearDown();
}
tearDown s’exécute après chaque méthode de test, y compris si ce test a échoué. Son rôle est de remettre l’environnement dans un état neutre, ici en réinitialisant l’utilisateur courant à zéro, pour qu’un test suivant ne trouve pas, par erreur, un utilisateur encore connecté d’un test précédent. Sur WP_UnitTestCase, une grande partie de ce nettoyage, notamment la base de données, est déjà prise en charge automatiquement, mais tout état global manipulé explicitement dans un test mérite d’être restauré ici.
Assertion : la vérification elle-même
Une assertion est l’instruction qui compare une valeur obtenue à une valeur attendue, et qui fait échouer le test si elles ne correspondent pas. assertTrue, assertSame, assertCount sont des exemples d’assertions fournies par PHPUnit. Une assertion ne prépare jamais rien : son unique rôle est de vérifier, une fois que la fixture est en place et que le code testé a été exécuté.
| Terme | Rôle | Moment d’exécution |
|---|---|---|
| Fixture | État préparé nécessaire au test | Avant l’appel du code testé |
| setUp | Construit la fixture automatiquement | Avant chaque méthode de test |
| Assertion | Compare le résultat obtenu à l’attendu | Après l’appel du code testé |
| tearDown | Remet l’environnement à l’état neutre | Après chaque méthode de test |
Retenir l’ordre suffit à comprendre n’importe quelle classe de test : préparer, agir, vérifier, nettoyer. Toute la structure de PHPUnit découle de ces quatre étapes répétées pour chaque méthode de test.
Une confusion fréquente à éviter
Un piège classique consiste à placer une assertion à l’intérieur de setUp, pour « vérifier que la fixture est bien construite ». Cette pratique mélange deux responsabilités qui doivent rester séparées : si la fixture elle-même échoue à se construire, le test échouera de toute façon, souvent avec une erreur explicite, sans qu’il soit nécessaire d’ajouter une vérification supplémentaire à cet endroit. Garder setUp concentré sur la préparation, et les assertions concentrées dans le corps du test, garde chaque méthode facile à comprendre isolément.
En résumé
Fixture, setUp, assertion et tearDown ne sont pas du jargon impénétrable : ce sont quatre notions précises qui décrivent le cycle de vie complet d’un test, préparer un état connu, agir, vérifier, puis nettoyer. Une fois ce vocabulaire assimilé avec un exemple concret ancré dans WordPress, la lecture de n’importe quelle classe de test PHPUnit devient nettement plus rapide, même sur un projet jamais vu auparavant.
