3 lignes de code suffisent pour créer un article, un utilisateur et une catégorie complets, prêts à être utilisés dans un test, sans jamais toucher à la base de données du site en développement. C’est ce que proposent les factories intégrées à la suite de tests officielle de WordPress, un mécanisme souvent découvert tardivement par les développeurs qui débutent avec les tests d’intégration.
Avant de connaître ce mécanisme, un développeur junior a tendance à préparer ses données de test manuellement, dans l’interface d’administration d’une installation locale, puis à écrire ses tests en s’appuyant sur les identifiants de ces contenus créés à la main. Cette approche fonctionne un temps, jusqu’à ce que la base de développement devienne encombrée de contenus de test, ou que ces identifiants changent après une réinstallation.
Le problème d’une préparation manuelle
Créer un article manuellement pour tester une fonction pose plusieurs difficultés qui apparaissent rapidement :
- L’identifiant de l’article créé dépend de l’historique de la base, ce qui rend le test fragile dès qu’un autre contenu est ajouté ou supprimé avant lui.
- Un autre développeur qui récupère le projet doit recréer manuellement les mêmes contenus pour que les tests fonctionnent chez lui, une étape souvent oubliée ou mal documentée.
- La base de développement accumule, au fil des mois, des dizaines de contenus créés uniquement pour des tests ponctuels, jamais nettoyés.
La solution intégrée : self::factory()
class ArticleVisibiliteTest extends WP_UnitTestCase {
public function test_article_publie_est_visible(): void {
$post_id = self::factory()->post->create( [
'post_status' => 'publish',
'post_title' => 'Article de test',
] );
$this->assertSame( 'publish', get_post_status( $post_id ) );
}
}
Cette méthode statique factory(), fournie par WP_UnitTestCase, donne accès à des générateurs dédiés pour chaque type de contenu WordPress : post, user, term, comment, attachment, entre autres. Chaque appel à create insère réellement une ligne en base de données, mais dans une transaction qui sera annulée automatiquement une fois le test terminé, quel que soit son résultat.
Créer plusieurs contenus liés en quelques lignes
public function test_article_avec_auteur_et_categorie(): void {
$auteur_id = self::factory()->user->create( [ 'role' => 'author' ] );
$categorie_id = self::factory()->category->create( [ 'name' => 'Tutoriels' ] );
$post_id = self::factory()->post->create( [
'post_author' => $auteur_id,
'post_category' => [ $categorie_id ],
] );
$this->assertSame( $auteur_id, (int) get_post( $post_id )->post_author );
$this->assertTrue( has_category( 'Tutoriels', $post_id ) );
}
Aucune de ces trois créations ne nécessite d’ouvrir l’interface d’administration ni de préparer un état préalable dans la base : chaque appel construit exactement ce dont le test a besoin, au moment où il en a besoin, avec des valeurs par défaut sensées pour tous les champs non précisés explicitement.
Créer plusieurs éléments d’un coup
public function test_pagination_avec_quinze_articles(): void {
self::factory()->post->create_many( 15 );
$requete = new WP_Query( [ 'posts_per_page' => 10 ] );
$this->assertCount( 10, $requete->posts );
$this->assertSame( 15, $requete->found_posts );
}
create_many permet de générer rapidement un volume de contenus suffisant pour tester une logique de pagination ou de limite, sans avoir à écrire une boucle manuelle répétant l’appel à create autant de fois que nécessaire.
Pourquoi aucune donnée ne persiste après le test
WP_UnitTestCase encapsule chaque méthode de test individuelle dans une transaction de base de données, ouverte dans setUp et annulée dans tearDown. Tout ce qui est créé via une factory pendant le test, article, utilisateur ou terme, disparaît donc automatiquement à la fin de ce test précis, sans intervention manuelle du développeur. C’est ce mécanisme qui garantit qu’un test suivant démarre toujours sur une base propre, quel que soit le volume de données créé par les tests précédents.
Un développeur qui débute avec les tests d’intégration WordPress ne devrait jamais avoir besoin d’ouvrir l’interface d’administration pour préparer une donnée de test : si un article ou un utilisateur est nécessaire, la factory doit le créer, dans le test lui-même.
Personnaliser les valeurs par défaut d’une factory
Quand un projet a besoin systématiquement d’un même jeu de valeurs par défaut différentes de celles fournies nativement, il est possible d’étendre les classes de factory du cœur pour créer une factory personnalisée, réutilisable ensuite dans toute la suite de tests du projet. Cette personnalisation reste toutefois une étape avancée : pour un développeur débutant, les factories natives, utilisées directement avec quelques arguments explicites, suffisent largement à couvrir l’immense majorité des besoins.
En résumé
Les factories intégrées à la suite de tests de WordPress évitent la préparation manuelle de données dans une base de développement, éliminent le risque de pollution progressive de cette base, et garantissent que chaque test reste reproductible pour n’importe quel développeur qui récupère le projet. Pour un développeur junior, adopter ce réflexe dès les premiers tests écrits évite une habitude bien plus difficile à corriger une fois ancrée.
