Un test qui grossit avec le temps finit souvent par ressembler à un roman : préparation mêlée à l’action, assertions dispersées entre deux appels, condition ajoutée en urgence sans qu’on sache trop où elle a sa place. Arrange-Act-Assert (souvent abrégé AAA) n’est pas un outil ni une bibliothèque, c’est une convention d’écriture qui remet chaque instruction à sa place.
Le principe tient en une phrase : chaque test se découpe en trois blocs successifs, jamais entremêlés, séparés par une ligne vide. Ce billet ne traite ni les bibliothèques d’assertion ni le développement piloté par le comportement (BDD), qui reposent sur d’autres conventions ; il se concentre sur ce que ce découpage change concrètement dans un projet WordPress.
Ce que chaque bloc contient, et rien d’autre
Arrange prépare tout ce dont le test a besoin : création d’un article, réglage d’une option, instanciation d’une classe. Act déclenche l’unique action que le test évalue. Assert vérifie le résultat, et seulement le résultat attendu par ce test précis.
public function test_article_expire_passe_en_brouillon() {
// Arrange
$id = $this->factory->post->create( [
'post_status' => 'publish',
'meta_input' => [ 'date_expiration' => '2020-01-01' ],
] );
$gestionnaire = new Gestionnaire_Expiration();
// Act
$gestionnaire->traiter_articles_expires();
// Assert
$this->assertSame( 'draft', get_post_status( $id ) );
}
Rien de nouveau techniquement : c’est le même PHPUnit, les mêmes assertions. Ce qui change, c’est qu’un développeur qui ouvre ce test six mois plus tard sait immédiatement où regarder pour comprendre le contexte, où pour comprendre l’action, où pour comprendre l’attendu.
Le symptôme d’un test qui mélange les blocs
Voici la même intention, écrite sans discipline :
public function test_article_expire_passe_en_brouillon() {
$gestionnaire = new Gestionnaire_Expiration();
$id = $this->factory->post->create( [ 'post_status' => 'publish' ] );
update_post_meta( $id, 'date_expiration', '2020-01-01' );
$this->assertSame( 'publish', get_post_status( $id ) );
$gestionnaire->traiter_articles_expires();
$this->assertSame( 'draft', get_post_status( $id ) );
}
Ce test fonctionne, mais il fait deux choses à la fois : il vérifie un état initial (implicite, non annoncé) puis l’effet de l’action. Un lecteur pressé peut confondre les deux assertions, ou pire, un futur ajout de logique peut être inséré n’importe où dans cette séquence sans que rien ne l’en empêche.
Une seule action, une seule intention
La discipline AAA impose implicitement une autre règle utile : un seul « Act » par test. Si deux actions distinctes semblent nécessaires pour vérifier un comportement, c’est souvent le signe que le test couvre deux intentions différentes et devrait être scindé en deux méthodes.
- Un test, une action déclenchée, un comportement vérifié.
- Si l’assertion porte sur plusieurs aspects indépendants, préférer plusieurs méthodes de test nommées séparément.
- Le bloc Arrange peut être long ; ce n’est pas un défaut du pattern, c’est le reflet du nombre de préconditions réelles.
Ce que cette convention change dans la maintenance
Sur une suite de plusieurs centaines de tests, la valeur d’AAA se voit surtout à la relecture d’une pull request. Un relecteur qui sait que chaque test suit ce schéma peut sauter directement au bloc Assert pour vérifier que le comportement couvert correspond bien à la description du ticket, sans devoir dérouler tout l’Arrange en détail.
Elle facilite aussi la détection d’un test fragile : si l’Arrange dépasse largement l’Act et l’Assert réunis, cela signale souvent une classe trop couplée à son environnement, qui nécessite trop de préparation pour être testée isolément. Le pattern ne corrige pas ce problème de conception, mais il le rend visible plus tôt qu’un test écrit en continu.
Une variante utile : les commentaires implicites
Beaucoup d’équipes abandonnent les commentaires // Arrange, // Act, // Assert une fois la convention acquise, et se contentent de la ligne vide entre les blocs. Le repère visuel suffit, et l’absence de commentaire évite qu’il ne devienne obsolète si le code bouge sans que le commentaire suive.
Un test dont l’Arrange fait vingt lignes n’est pas un mauvais test ; c’est un signal que la classe testée mérite peut-être d’être découpée.
En résumé
Arrange-Act-Assert ne change rien à la mécanique de PHPUnit ; ce pattern impose seulement un ordre et une séparation visuelle. Sur une extension WordPress dont la suite de tests s’étoffe au fil des mois, cette discipline simple réduit le temps de relecture et rend visible, bien avant qu’il ne devienne un problème, un test qui tente de vérifier trop de choses à la fois.
