# Ce qu’un relecteur doit vérifier dans une contribution qui ajoute des tests

> Approuver des tests sans vraiment les lire laisse passer un mock trop permissif ou une assertion trop large. Une grille de lecture pour repérer un test qui ne teste rien.

- Auteur : WordPress Développement
- Publié le : 2022-09-13
- Mis à jour le : 2022-09-13
- Catégorie : Tests
- URL : https://www.wpmoderne.fr/tests/grille-relecture-contribution-tests/

## L’essentiel

- Un test qui passe sans le code testé n'a rien vérifié
- Un mock trop permissif accepte n'importe quel argument sans jamais échouer
- Une assertion trop large masque une régression réelle sur un détail du résultat

« Approuvé, la suite passe au vert » : ce commentaire de revue ne dit rien de ce qui a été vérifié dans les tests ajoutés eux-mêmes. Un test qui ne teste en réalité rien du tout peut se cacher derrière un statut vert, et personne ne s'en rend compte avant qu'une régression traverse une suite censée l'attraper, plusieurs mois plus tard. Un relecteur qui vérifie uniquement que la suite passe au vert, sans lire le contenu des tests ajoutés, laisse passer ce genre de problème sans le savoir.

Ce billet propose une grille de lecture pour repérer, en quelques minutes, un test qui ne teste rien, un mock trop permissif ou une assertion trop large ; il ne traite pas la revue du code de production, qui suit d'autres critères.

## Vérification 1 : le test échoue-t-il vraiment sans le code testé ?

Le doute le plus fondamental à lever : ce test échouerait-il si le code qu'il est censé vérifier était supprimé ou cassé délibérément ? Un relecteur qui a un doute peut demander, en commentaire, de commenter temporairement la ligne clé du code de production pour confirmer que le test échoue bien dans ce cas.

```
public function test_remise_appliquee_apres_six_mois() {
    $calculateur = new Fidelite_Calculateur();
    $remise = $calculateur->calculer( 12, 100.00 );

    $this->assertIsFloat( $remise );
    // Cette assertion passe même si la méthode renvoie toujours 0.00 !
}
```

Ici, `assertIsFloat` vérifie uniquement le type retourné, jamais la valeur réelle attendue. Le test passe même si la logique de remise est entièrement cassée, tant que la méthode renvoie un nombre flottant quelconque.

## Vérification 2 : le mock accepte-t-il n'importe quel argument ?

Un mock configuré sans contrainte sur ses arguments accepte n'importe quel appel, ce qui masque une erreur d'implémentation là où le mock aurait dû échouer :

```
// Trop permissif : accepte n'importe quel argument
WP_Mock::userFunction( 'wp_mail' );

// Explicite : échoue si l'appel ne correspond pas exactement
WP_Mock::userFunction( 'wp_mail', [
    'args' => [ 'client@exemple-test.invalid', 'Confirmation de commande', Mockery::type( 'string' ) ],
    'times' => 1,
] );
```

> L'essentiel à retenir : Un test qui passe sans le code testé n'a rien vérifié ; Un mock trop permissif accepte n'importe quel argument sans jamais échouer ; Une assertion trop large masque une régression réelle sur un détail du résultat

## Vérification 3 : l'assertion est-elle assez précise ?

Une assertion large, comme `assertNotEmpty` sur un tableau attendu avec un contenu précis, laisse passer un résultat presque correct mais faux sur un détail important. Comparer une liste triée avec `assertEqualsCanonicalizing`, ou une structure complète avec `assertSame`, réduit ce risque par rapport à une vérification partielle du résultat.

| Assertion vague | Assertion précise équivalente |
| --- | --- |
| assertNotEmpty( $resultat ) | assertSame( $resultat_attendu, $resultat ) |
| assertTrue( is_array( $resultat ) ) | assertCount( 3, $resultat ) |
| assertIsString( $sortie ) | assertStringContainsString( 'Confirmation', $sortie ) |

## Vérification 4 : le test a-t-il un nom qui décrit un seul comportement ?

Un test au nom générique, ou qui contient plusieurs assertions couvrant des comportements distincts sans lien logique entre eux, complique le diagnostic en cas d'échec futur. Un relecteur attentif demande une scission du test si son nom et son contenu ne correspondent manifestement pas à une seule intention claire.

## La grille en une liste courte

1. Ce test échouerait-il si le comportement testé était cassé délibérément ?
2. Chaque mock impose-t-il une contrainte réelle sur ses arguments et le nombre d'appels attendus ?
3. L'assertion finale vérifie-t-elle le contenu précis attendu, pas seulement sa présence ou son type ?
4. Le nom du test correspond-il exactement à ce qui est vérifié dans son corps ?

> Un relecteur qui n'a pas le temps de lire un test en détail devrait au minimum poser la question : « que se passe-t-il si je supprime ce code, ce test échoue-t-il vraiment ? »

## En résumé

Une pull request qui ajoute des tests mérite une lecture aussi attentive que le code de production qu'elle prétend couvrir. Vérifier que le test échouerait sans le code testé, que les mocks imposent de vraies contraintes et que les assertions sont suffisamment précises permet de repérer, en quelques minutes, un test qui donne une fausse confiance plutôt qu'une réelle protection contre la régression.