Diskussion: Tabellengetriebene Tests in Go mit Subtests

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Maschinelle Übersetzung; massgebend ist das Original. Original

Schritt 5 wird als Stellschraube für die Geschwindigkeit angeboten, aber `t.Parallel()` innerhalb einer Schleife über Testfälle verändert die Ausführungsreihenfolge auf eine Weise, die die Methodik nicht erwähnt, und diese Änderung lässt das gängigste Test-Setup scheitern. Ein paralleler Subtest wird angehalten, bis der Funktionskörper seines übergeordneten Tests zurückkehrt; erst dann werden die parallelen Tabellenzeilen ausgeführt. Daher schliesst `db := open(); defer db.Close()` am Anfang des übergeordneten Tests, gefolgt von der Schleife, die Datenbank, bevor irgendeine parallele Zeile ausgeführt wird, und jede Zeile schlägt dann mit einem Fehler wegen einer geschlossenen Verbindung fehl, der nichts mit ihrem Testfall zu tun hat. Die eigene Lösung der Testdokumentation besteht darin, die Schleife in ein zusätzliches `t.Run("group", …)` zu verschachteln, sodass das Aufräumen nach diesem Aufruf erfolgt, sobald alle Zeilen abgeschlossen sind, oder das Aufräumen im übergeordneten Test mit `t.Cleanup` zu registrieren, das nach Abschluss seiner Subtests ausgeführt wird; Schritt 4 erwähnt `t.Cleanup` für Hilfsfunktionen, aber nicht diesen Grund. Bei parallelen Zeilen werden ausserdem die Log-Ausgaben ineinander verschachtelt, sodass die `t.Log`-Zeilen einer fehlgeschlagenen Zeile von ihrer Fehlerzeile getrennt sind, und bei Modulen mit einer Go-Version unter 1.22 wird die Schleifenvariable gemeinsam genutzt, sodass jede Zeile den letzten Fall sieht, sofern die Variable nicht kopiert wird. Zeilen nur dann als parallel markieren, wenn das Setup pro Zeile erfolgt und mit `t.Cleanup` registriert ist; eine Tabelle mit Testfällen für reine Funktionen ist gewöhnlich auch ohne Parallelisierung schnell genug.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

Details of the `-run` step that are easy to get wrong. The `testing` package rewrites subtest names: spaces become underscores (a case named `empty input` is matched as `empty_input`, which is why the article's example works), and a name that repeats within one parent gets a `#01`, `#02` suffix, so duplicate row names do not fail but become unaddressable by their plain name. Since Go 1.20 the complementary `-skip` flag takes the same slash-separated regular expression and excludes matching tests or subtests, handy for skipping one broken row without editing the table. `t.Setenv` and `t.Chdir` (Go 1.24) panic when called from a test that has called `t.Parallel()` or has a parallel ancestor, so a table whose rows set environment variables cannot use step 5. `go test -shuffle=on` (Go 1.17) randomises the order of top-level tests and benchmarks, not of subtests; row order inside a table stays fixed, so an order dependence between rows only shows up when a single row is run with `-run`.