Tabellengetriebene Tests in Go mit Subtests

Ziel

Viele Eingaben einer Funktion mit einem lesbaren Test abdecken, bei dem das Hinzufügen eines Falls eine Zeile bedeutet und ein fehlschlagender Fall in der Ausgabe namentlich genannt wird.

Voraussetzungen

Eine Funktion mit klarem Vertrag zwischen Eingabe und Ausgabe, das Standardpaket testing (kein Framework nötig) und die unter „Subtests and Sub-benchmarks“ dokumentierte Subtest-Funktionalität: t.Run(name, func(t *testing.T)) erzeugt einen benannten Subtest, dessen vollständiger Name aus dem Namen des übergeordneten Tests und dem Namen des Subtests, durch einen Schrägstrich verbunden, besteht.

Schritte

1. Die Tabelle als Slice anonymer Structs mit einem Feld name, den Eingaben, der erwarteten Ausgabe und, wo relevant, wantErr bool oder einem Sentinel-Fehler zum Abgleich mit errors.Is definieren.
2. Mit for _, tc := range cases { t.Run(tc.name, func(t *testing.T) { ... }) } iterieren. Seit Go 1.22 (für Module, deren go.mod 1.22 oder neuer deklariert) besitzt jede Iteration ihre eigene Variable tc, sodass Closures den richtigen Fall erfassen; die Go-Wiki-Seite zeigt die iterationsweise Kopie, die ältere Versionen benötigten.
3. Innerhalb des Subtests die Funktion einmal aufrufen und dann vergleichen: t.Errorf, um den Fehler festzuhalten und fortzufahren, t.Fatalf, wenn spätere Prüfungen bedeutungslos wären (etwa ein nil-Ergebnis, das gleich dereferenziert würde).
4. Wiederkehrende Vorbereitung in einen Helper auslagern, der zuerst t.Helper() aufruft, damit Fehlerzeilen auf den Test statt auf den Helper zeigen; Aufräumarbeiten mit t.Cleanup registrieren.
5. Unabhängige Subtests mit t.Parallel() markieren, sofern die Funktion nebenläufig aufgerufen werden darf; die Dokumentation besagt, dass ein Run, das parallele Subtests umschliesst, erst zurückkehrt, wenn diese abgeschlossen sind — so lässt sich nach einer Gruppe von ihnen aufräumen.
6. Beim Debuggen einen einzelnen Fall ausführen: go test -run 'TestParse/empty_input'; das Argument -run ist durch Schrägstriche gegliedert und gleicht jedes Namenselement der Reihe nach ab.
7. Wird ein Fehler gefunden, die fehlschlagende Eingabe vor der Behebung als neue Zeile hinzufügen.

Erwartetes Ergebnis

Eine Testdatei, deren Fälle sich wie eine Spezifikationstabelle lesen; eine Ausgabe wie --- FAIL: TestParse/negative_width zeigt direkt auf die Zeile; ein neuer Fall kostet eine Zeile.

Grenzen und Prüfbasis

Tabellen eignen sich für reine Funktionen und kleine Zustandsautomaten; sie werden unhandlich, wenn Fälle unterschiedliche Vorbereitung brauchen oder Unterschiedliches prüfen — dann sind separate Tests klarer als eine Tabelle voller optionaler Felder. Fallnamen werden Teil des -run-Musters, das ein regulärer Ausdruck ist; sie sollten deshalb kurz, eindeutig und frei von Metazeichen bleiben. Das Vorgehen folgt der zitierten testing-Dokumentation und der Go-Wiki-Seite zu tabellengetriebenen Tests.