Tests in Go-Unterordnern: Eine vollständige Analyse für Anfänger

Tests in Go-Unterordnern: Das Problem lösen, über das Tutorials schweigen

Haben Sie jemals Tests in Go geschrieben und festgestellt, dass sie im Projektstammverzeichnis einwandfrei funktionieren, aber sobald Sie sie in einen Unterordner verschieben, alles kaputt geht? Kommt Ihnen das bekannt vor? Wenn ja, sind Sie nicht allein. Die Frage "Golang tests in sub-directory" auf Stack Overflow hat tausende Aufrufe. Und das ist nicht verwunderlich: Die Go-Dokumentation behandelt dieses Thema trocken, und Anfänger sind oft verwirrt.

In diesem Artikel werden wir uns ansehen, wie man Go-Tests mit verschachtelten Paketen richtig organisiert, warum das notwendig ist und wie man typische Fallstricke vermeidet. Los geht's!

Warum sind Tests in Unterordnern eine Herausforderung?

Stellen Sie sich vor: Sie haben ein Projekt mit folgender Struktur:

myapp/\n├── main.go\n├── go.mod\n└── utils/\n    ├── math.go\n    └── math_test.go

Sie führen Go test im Stammverzeichnis aus – und alles funktioniert. Aber wenn Sie versuchen, die Tests aus dem Ordner utils auszuführen, beschwert sich Go: "package myapp/utils is not in GOROOT". Ein bekannter Fehler?

Das Problem ist, dass Go mit Paketen arbeitet, nicht mit Ordnern. Wenn Sie einen Unterordner erstellen, erstellen Sie tatsächlich ein neues Paket. Und die Tests darin müssen unter Berücksichtigung der Modulstruktur des Projekts ausgeführt werden. Aber der Reihe nach.

Grundlagen: Wie Go Tests sieht

In Go sind Tests normale Dateien mit dem Suffix _test.go. Sie können sich befinden:

\n
• Im selben Paket (White-Box-Tests) – haben Zugriff auf nicht exportierte Funktionen.
\n
• In einem separaten Paket mit dem Suffix _test (Black-Box-Tests) – testen das Paket wie ein externer Benutzer.
\n

Wenn Sie Tests in einen Unterordner legen, erstellen Sie ein neues Paket. Zum Beispiel ist der Ordner utils das Paket utils. Und die Tests darin müssen zu diesem Paket gehören.

Beispiel einer korrekten Struktur

myapp/\n├── go.mod\n├── main.go\n└── utils/\n    ├── math.go        // package utils\n    └── math_test.go   // package utils

In der Datei math.go:

package utils\n\nfunc Add(a, b int) int {\n    return a + b\n}

In der Datei math_test.go:

package utils\n\nimport "testing"\n\nfunc TestAdd(t *testing.T) {\n    result := Add(2, 3)\n    if result != 5 {\n        t.Errorf("Expected 5, got %d", result)\n    }\n}

Führen Sie nun die Tests aus dem Stammverzeichnis des Projekts aus:

go test ./utils/

Oder aus dem Ordner utils:

cd utils\ngo test

Alles funktioniert! Aber was ist, wenn Sie eine komplexere Struktur haben?

Verschachtelte Unterordner: Tiefer als es scheint

Angenommen, Sie haben ein Projekt mit dieser Struktur:

myapp/\n├── go.mod\n├── main.go\n└── services/\n    ├── user/\n    │   ├── user.go\n    │   └── user_test.go\n    └── order/\n        ├── order.go\n        └── order_test.go

Hier ist jeder Unterordner ein separates Paket. Um alle Tests rekursiv auszuführen, verwenden Sie drei Punkte:

go test ./...

Dieser Befehl findet alle Pakete im Projekt und führt deren Tests aus. Sehr praktisch für CI/CD!

Was ist, wenn Tests im selben Ordner wie der Code sind?

Manchmal legen Entwickler Tests in denselben Ordner wie den Hauptcode. Das ist für kleine Projekte in Ordnung. Für große Projekte ist es jedoch besser, Tests in separate Unterordner auszulagern – so wird die Struktur sauberer.

Typische Fehler und ihre Lösungen

Lassen Sie uns die häufigsten Probleme analysieren, auf die Anfänger bei der Arbeit mit Golang tests in sub-directory stoßen.

Fehler 1: "package is not in GOROOT"

Ursache: Sie versuchen, einen Test aus einem Unterordner auszuführen, ohne das Modul anzugeben. Go weiß nicht, zu welchem Modul das Paket gehört.

Lösung: Stellen Sie sicher, dass Sie eine go.mod-Datei im Stammverzeichnis haben.