Go-Testing von Grund auf: Ein Leitfaden für Anfänger

Warum Testing in Go nicht beängstigend, sondern notwendig ist

Wenn Sie zum ersten Mal in Go schreiben, scheint es, als würde der Compiler fast alles abfangen: strenge Typen, explizite Fehler, nil unter Kontrolle. Aber sobald Ihr Projekt auf über 500 Zeilen anwächst, wird Ihnen klar: Ohne Tests kann man nicht leben. Eine Änderung an einer Stelle zerstört eine andere, und Sie erfahren davon erst in der Produktion.

In diesem Artikel zeige ich Ihnen, wo ein Anfänger mit dem Testen in Go beginnen kann. Wir befassen uns mit Unit-Tests, tabellarischen Tests, Mocks und Code Coverage. Kein unnötiges Gerede – nur funktionierende Beispiele und praktische Ratschläge.

Wenn Sie seit mindestens ein paar Monaten in Go schreiben, spart Ihnen dieses Material Stunden beim Debuggen.

Was Sie vor dem Start wissen müssen

Go bietet ein integriertes Paket testing – es muss nichts zusätzlich installiert werden. Tests werden in Dateien mit dem Suffix _test.go geschrieben und mit dem Befehl ausgeführt:

go test ./...

Die grundlegenden Regeln:

\n
• Die Testfunktion muss TestXxx(t *testing.T) heißen, wobei Xxx der Name der zu testenden Funktion in Großschreibung ist.
\n
• Testdateien liegen neben dem zu testenden Code.
\n
• Fehler werden über t.Error() oder t.Fatal() gemeldet.
\n

Kommen wir direkt zur Praxis.

Unseren ersten Unit-Test in Go schreiben

Angenommen, wir haben eine einfache Funktion, die zwei Zahlen summiert:

// calc.go\npackage calc\n\nfunc Sum(a, b int) int {\n    return a + b\n}

Erstellen Sie die Datei calc_test.go im selben Ordner:

// calc_test.go\npackage calc\n\nimport "testing"\n\nfunc TestSum(t *testing.T) {\n    result := Sum(2, 3)\n    expected := 5\n\n    if result != expected {\n        t.Errorf("Sum(2,3) = %d; want %d", result, expected)\n    }\n}

Führen Sie den Test aus:

go test -v

Sie sehen ein grünes PASS – Ihr erster Testsieg. Beachten Sie: Wir verwenden t.Errorf (nicht fatal) – der Test wird fortgesetzt, auch wenn ein Fall fehlschlägt.

Tabellarische Tests: Wenn ein einzelner Test unpraktisch ist

Stellen Sie sich vor, Sie müssen eine Funktion mit einem Dutzend verschiedener Eingabedaten testen. 10 separate Tests schreiben? Nein, in Go gibt es dafür tabellarische Tests (table-driven tests). Dies ist der Standard in der Go-Community.

Fügen wir in unserer calc.go eine Divisionsfunktion hinzu:

func Divide(a, b int) (int, error) {\n    if b == 0 {\n        return 0, errors.New("division by zero")\n    }\n    return a / b, nil\n}

Jetzt schreiben wir einen tabellarischen Test:

func TestDivide(t *testing.T) {\n    tests := []struct {\n        name     string\n        a, b     int\n        expected int\n        wantErr  bool\n    }{\n        {"positive", 10, 2, 5, false},\n        {"negative", -6, 3, -2, false},\n        {"zero division", 5, 0, 0, true},\n        {"same numbers", 7, 7, 1, false},\n    }\n\n    for _, tt := range tests {\n        t.Run(tt.name, func(t *testing.T) {\n            got, err := Divide(tt.a, tt.b)\n            if tt.wantErr {\n                if err == nil {\n                    t.Error("expected error, got nil")\n                }\n                return\n            }\n            if err != nil {\n                t.Errorf("unexpected error: %v", err)\n            }\n            if got != tt.expected {\n                t.Errorf("Divide(%d,%d) = %d; want %d", tt.a, tt.b, got, tt.expected)\n            }\n        })\n    }\n}

Was hier großartig ist:

\n
• Jeder Fall ist ein separater Untertest mit einem Namen. Wenn einer fehlschlägt, werden die anderen ausgeführt.
\n
• Neue Fälle lassen sich leicht hinzufügen – Sie fügen einfach eine Zeile in die Struktur ein.
\n
• Der Code liest sich wie eine Spezifikation.
\n

Führen Sie es mit dem Flag -v aus – Sie sehen die Namen aller Untertests. Das ist beim Debuggen sehr praktisch.

Testen von