Tests dans les sous-dossiers Go : analyse complète pour débutants

Tests dans les sous-dossiers Go : résolvons le problème dont les tutoriels ne parlent pas

Avez-vous déjà écrit des tests en Go et constaté qu'ils fonctionnent parfaitement à la racine du projet, mais dès que vous les déplacez dans un sous-dossier, tout se casse ? Cela vous dit quelque chose ? Si oui, vous n'êtes pas seul. La question "Golang tests in sub-directory" sur Stack Overflow a recueilli des milliers de vues. Et ce n'est pas surprenant : la documentation Go en parle de manière succincte, et les développeurs débutants sont souvent perdus.

Dans cet article, nous allons comprendre comment organiser correctement les tests Go en utilisant des packages imbriqués, pourquoi c'est nécessaire et comment éviter les pièges. C'est parti !

Pourquoi les tests dans les sous-dossiers sont-ils un problème ?

Imaginez : vous avez un projet dont la structure ressemble à ceci :

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

Vous exécutez Go test à la racine - et tout fonctionne. Mais lorsque vous essayez d'exécuter les tests depuis le dossier utils, Go râle : "package myapp/utils is not in GOROOT". Une erreur familière ?

Le problème est que Go fonctionne avec des packages, pas avec des dossiers. Lorsque vous créez un sous-dossier, vous créez en fait un nouveau package. Et les tests dans ce dossier doivent être exécutés en tenant compte de la structure modulaire du projet. Mais procédons dans l'ordre.

Les bases : comment Go voit les tests

En Go, les tests sont des fichiers ordinaires avec le suffixe _test.go. Ils peuvent se trouver :

\n
• Dans le même package (tests blancs) - ils ont accès aux fonctions non exportées.
\n
• Dans un package séparé avec le suffixe _test (tests noirs) - ils testent le package comme un utilisateur externe.
\n

Lorsque vous placez des tests dans un sous-dossier, vous créez un nouveau package. Par exemple, le dossier utils est le package utils. Et les tests qu'il contient doivent appartenir à ce package.

Exemple de structure correcte

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

Dans le fichier math.go :

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

Dans le fichier 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}

Exécutez maintenant les tests depuis la racine du projet :

go test ./utils/

Ou depuis le dossier utils :

cd utils\ngo test

Tout fonctionne ! Mais que faire si vous avez une structure plus complexe ?

Sous-dossiers imbriqués : plus profond qu'il n'y paraît

Supposons que vous ayez un projet avec cette structure :

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

Ici, chaque sous-dossier est un package séparé. Pour exécuter tous les tests de manière récursive, utilisez trois points :

go test ./...

Cette commande trouvera tous les packages du projet et exécutera leurs tests. Très pratique pour le CI/CD !

Et si les tests sont dans le même dossier que le code ?

Parfois, les développeurs placent les tests dans le même dossier que le code principal. C'est acceptable pour les petits projets. Mais pour les grands projets, il est préférable de placer les tests dans des sous-dossiers séparés - la structure devient plus propre.

Erreurs typiques et leurs solutions

Examinons les problèmes les plus courants rencontrés par les débutants lorsqu'ils travaillent avec Golang tests in sub-directory.

Erreur 1 : "package is not in GOROOT"

Cause : Vous essayez d'exécuter un test depuis un sous-dossier sans spécifier le module. Go ne sait pas à quel module appartient le package.

Solution : Assurez-vous d'avoir un fichier go.mod à la racine