Comment afficher des données dans les tests Go : les secrets de t.Log() et t.Logf() en 2025

Introduction : La question éternelle « Comment afficher quelque chose dans un test ? »

Vous écrivez un test en Go. La logique est complexe, les données sont embrouillées, et vous avez absolument besoin de voir ce qui se passe à l'intérieur. Vous écrivez machinalement fmt.Println("value =", x), vous lancez le test... et vous voyez le silence. Aucun affichage. Cela vous dit quelque chose ?

Cette question est l'une des plus populaires sur Stack Overflow parmi les développeurs Go débutants (et pas seulement !). Il semble que quoi de plus simple que d'afficher une chaîne ? Mais dans le monde des tests Go, il y a ses propres règles et un ensemble d'outils de gentleman. Dans cet article, nous allons passer en revue toutes les méthodes d'affichage dans les tests, organiser les meilleures pratiques de 2025 et montrer comment éviter les erreurs. C'est parti !

Pourquoi fmt.Println se tait-il ? (Et quand parle-t-il enfin ?)

Allons droit au but. Lorsque vous lancez les tests avec la commande go test (sans drapeaux), la sortie standard (stdout) est supprimée. Le testeur Go considère que si le test a réussi, l'utilisateur n'a pas besoin de voir des tonnes d'informations de débogage. Cela est fait pour la propreté et l'automatisation — imaginez si chaque test affichait 10 lignes de log à chaque exécution CI/CD.

Cependant, il y a deux exceptions où fmt.Println apparaîtra quand même à l'écran :

\n
• Le drapeau -v (verbose) : go test -v. Ce mode active l'affichage détaillé de tous les tests. Vous verrez les messages de fmt.Println et d'autres fonctions.
\n
• Le test a échoué : Si le test se termine avec une erreur (appel à t.Error ou t.Fatal), alors l'affichage de fmt.Println de ce test sera montré. C'est très utile pour le débogage.
\n

Mais compter sur fmt.Println est de mauvais goût. Pour les tests en Go, il existe un outil spécial, plus correct et plus puissant.

Le roi de la fête : t.Log() et t.Logf()

L'objet testing.T (qui est passé à chaque test) possède des méthodes intégrées pour la journalisation. Retenez-les comme « Notre Père » : t.Log() et t.Logf().

package main\n\nimport (\n    "testing"\n)\n\nfunc TestSum(t *testing.T) {\n    result := 2 + 2\n    // Journalisation simple\n    t.Log("Début du test de somme")\n    t.Log("Résultat du calcul :", result)\n\n    // Journalisation avec formatage (comme fmt.Printf)\n    t.Logf("La somme de 2 et 2 est %d. Vérification réussie !", result)\n\n    if result != 4 {\n        t.Errorf("Attendu 4, obtenu %d", result)\n    }\n}

Lancez ce test avec le drapeau -v :

go test -v -run TestSum

Et vous verrez de beaux messages structurés directement dans la sortie du test.

Pourquoi t.Log est-il meilleur que fmt.Println ?

\n
• Contexte : Les messages de t.Log sont automatiquement liés à un test spécifique. Dans la sortie -v, vous voyez quel test a imprimé quoi.
\n
• Contrôlabilité : L'affichage de t.Log n'est montré qu'avec -v ou en cas d'échec du test. Cela signifie que vos logs n'encombrent pas la console lors d'une exécution normale.
\n
• Sécurité : Contrairement à fmt.Fprintf(os.Stderr, ...), t.Log fonctionne correctement avec les tests parallèles (t.Parallel) et ne provoque pas de race condition.
\n

Le côté obscur de la force : t.Error() et t.Fatal() comme outil d'affichage

De nombreux débutants utilisent t.Error() uniquement pour arrêter le test en cas d'erreur. Mais en réalité, c'est un excellent (et correct !) moyen d'afficher des informations de diagnostic importantes, surtout lorsque le test échoue.

Le secret est que le message passé à t.Error() ou t.Fatal() sera toujours affiché, même sans le drapeau -v. Cela les rend idéaux pour afficher des informations critiques