Wie man Daten in Go-Tests ausgibt: Die Geheimnisse von t.Log() und t.Logf() im Jahr 2025

Einleitung: Die ewige Frage "Wie gebe ich etwas in einem Test aus?"

Sie schreiben einen Test in Go. Die Logik ist komplex, die Daten sind verworren, und Sie müssen unbedingt sehen, was im Inneren passiert. Automatisch schreiben Sie fmt.Println("value =", x), führen den Test aus... und sehen Stille. Keinerlei Ausgabe. Kommt Ihnen bekannt vor?

Diese Frage ist eine der beliebtesten auf Stack Overflow unter Anfängern (und nicht nur!) von Go-Entwicklern. Es scheint, was könnte einfacher sein, als eine Zeichenkette auszugeben? Aber in der Welt des Go-Testens gibt es eigene Regeln und einen feinen Werkzeugkasten. In diesem Artikel werden wir alle Methoden der Ausgabe in Tests durchgehen, die Best Practices für 2025 aufschlüsseln und zeigen, wie man keine Fehler macht. Los geht's!

Warum schweigt fmt.Println? (Und wann spricht es doch?)

Kommen wir direkt zur Sache. Wenn Sie Tests mit dem Befehl go test (ohne Flags) ausführen, wird die Standardausgabe (stdout) unterdrückt. Der Go-Tester geht davon aus, dass der Benutzer bei erfolgreichem Test keine Unmengen von Debug-Informationen sehen muss. Dies dient der Sauberkeit und Automatisierung – stellen Sie sich vor, jeder Test würde bei jedem CI/CD-Lauf 10 Zeilen Log ausgeben.

Es gibt jedoch zwei Ausnahmen, bei denen fmt.Println doch auf dem Bildschirm erscheint:

\n
• Das Flag -v (verbose): go test -v. Dieser Modus aktiviert die detaillierte Ausgabe aller Tests. Sie sehen Nachrichten von fmt.Println und anderen Funktionen.
\n
• Der Test ist fehlgeschlagen: Wenn ein Test mit einem Fehler endet (ausgelöst durch t.Error oder t.Fatal), wird die Ausgabe von fmt.Println aus diesem Test angezeigt. Dies ist sehr nützlich für das Debugging.
\n

Sich auf fmt.Println zu verlassen, ist jedoch schlechter Stil. Für Tests gibt es in Go ein spezielles, korrekteres und leistungsfähigeres Werkzeug.

Der König der Party: t.Log() und t.Logf()

Das Objekt testing.T (das an jeden Test übergeben wird) verfügt über integrierte Methoden zum Loggen. Merken Sie sie sich wie das "Vaterunser": t.Log() und t.Logf().

package main\n\nimport (\n    "testing"\n)\n\nfunc TestSum(t *testing.T) {\n    result := 2 + 2\n    // Einfaches Logging\n    t.Log("Starte den Summentest")\n    t.Log("Ergebnis der Berechnung:", result)\n\n    // Logging mit Formatierung (wie fmt.Printf)\n    t.Logf("Die Summe von 2 und 2 ist %d. Prüfung bestanden!", result)\n\n    if result != 4 {\n        t.Errorf("Erwartet 4, erhalten %d", result)\n    }\n}

Führen Sie diesen Test mit dem Flag -v aus:

go test -v -run TestSum

Und Sie sehen schöne, strukturierte Nachrichten direkt in der Testausgabe.

Warum ist t.Log besser als fmt.Println?

\n
• Kontext: Nachrichten von t.Log werden automatisch an den jeweiligen Test gebunden. In der -v-Ausgabe sehen Sie, welcher Test was gedruckt hat.
\n
• Steuerbarkeit: Die Ausgabe von t.Log wird nur bei -v oder bei einem Testfehler angezeigt. Das bedeutet, dass Ihre Logs die Konsole bei einem normalen Durchlauf nicht überladen.
\n
• Sicherheit: Im Gegensatz zu fmt.Fprintf(os.Stderr, ...) funktioniert t.Log korrekt mit parallelen Tests (t.Parallel) und verursacht keine Race Conditions.
\n

Die dunkle Seite der Macht: t.Error() und t.Fatal() als Ausgabewerkzeug

Viele Anfänger verwenden t.Error() nur, um den Test bei einem Fehler zu stoppen. Aber tatsächlich ist es eine hervorragende (und korrekte!) Methode, um wichtige diagnostische Informationen auszugeben, insbesondere wenn ein Test fehlschlägt.

Das Geheimnis ist, dass die an t.Error() oder t.Fatal() übergebene Nachricht immer angezeigt wird, selbst ohne das Flag -v. Das macht sie ideal für die Ausgabe von kritischen