Tests pilotés par table en Go avec les sous-tests

Objectif

Couvrir de nombreuses entrées d'une même fonction avec un seul test lisible, où ajouter un cas revient à ajouter une ligne, et où un cas en échec est nommé dans la sortie.

Prérequis

Une fonction avec un contrat entrée-sortie clair, le paquetage standard testing (aucun cadre externe requis), et le mécanisme de sous-tests documenté sous « Subtests and Sub-benchmarks » : t.Run(name, func(t *testing.T)) crée un sous-test nommé dont le nom complet est le nom du parent et le nom du sous-test joints par une barre oblique.

Étapes

1. Définir la table comme une slice de structures anonymes avec un champ name, les entrées, la sortie attendue et, le cas échéant, wantErr bool ou une erreur sentinelle à faire correspondre avec errors.Is.
2. Boucler avec for _, tc := range cases { t.Run(tc.name, func(t *testing.T) { ... }) }. Depuis Go 1.22 (pour les modules dont le go.mod déclare 1.22 ou une version ultérieure), chaque itération possède sa propre variable tc, si bien que les fermetures capturent le bon cas ; la page du wiki montre la copie par itération que nécessitaient les versions antérieures.
3. Dans le sous-test, appeler la fonction une fois, puis comparer : t.Errorf pour consigner l'échec et continuer, t.Fatalf lorsque les assertions suivantes n'auraient plus de sens (un résultat nul sur le point d'être déréférencé).
4. Déplacer la préparation répétée dans une fonction d'assistance qui appelle d'abord t.Helper(), afin que les lignes d'échec pointent vers le test plutôt que vers cette fonction ; enregistrer le nettoyage avec t.Cleanup.
5. Marquer les sous-tests indépendants avec t.Parallel() si la fonction peut être appelée sans risque de façon concurrente ; la documentation indique qu'un Run englobant des sous-tests parallèles ne renvoie la main qu'une fois ceux-ci terminés, ce qui permet de nettoyer après un groupe de sous-tests.
6. Exécuter un seul cas pendant le débogage : go test -run 'TestParse/empty_input' ; l'argument -run est séparé par des barres obliques et met en correspondance chaque élément de nom tour à tour.
7. Lorsqu'un bogue est trouvé, ajouter l'entrée en échec comme nouvelle ligne avant de le corriger.

Résultat attendu

Un fichier de test dont les cas se lisent comme une table de spécification ; une sortie telle que --- FAIL: TestParse/negative_width pointe directement vers la ligne concernée ; un nouveau cas ne coûte qu'une ligne.

Limites et base de vérification

Les tables conviennent aux fonctions pures et aux petites machines à états ; elles deviennent malcommodes lorsque les cas nécessitent une préparation différente ou vérifient des choses différentes, auquel cas des tests séparés sont plus clairs qu'une table remplie de champs optionnels. Les noms de cas font partie du motif -run, qui est une expression régulière ; il faut donc les garder courts, uniques et exempts de métacaractères. La procédure suit la documentation de test citée et la page du wiki Go sur les tests pilotés par table.