Tests de Golang dans le sous-répertoire

121

Je souhaite créer un package dans Go avec des tests et des exemples pour le package en tant que sous-répertoires afin de garder l'espace de travail plus propre. Est-ce possible, et si oui comment?

Toute la documentation place toujours le code de test au même endroit que l'autre code, est-ce mieux d'une certaine manière ou simplement par convention?

build go Le pingouin gracieux
la source
5
Remarque: go test ./...exécutera des tests sur le dossier actuel et tous les sous-dossiers. Voir ma réponse ci
VonC
Possible duplicata de Comment `tester 'tous les tests de mon projet?
Matthew Rankin
Je pensais la même chose. avoir du mal à mettre les tests dans un répertoire séparé car le répertoire du même niveau a des sous-répertoires.
filthy_wizard

Réponses:

203

Notez que vous pouvez exécuter go test"récursivement": vous devez lister tous les packages que vous souhaitez tester .

Si vous vous trouvez dans le dossier racine de votre projet Go, tapez:

go test ./...

La ./...notation ' ' est décrite dans la section " Description des listes de paquets " de la " commandego ":

Un chemin d'importation est un modèle s'il comprend un ou plusieurs ...caractères génériques " ", chacun pouvant correspondre à n'importe quelle chaîne, y compris la chaîne vide et les chaînes contenant des barres obliques.

Un tel modèle s'étend à tous les répertoires de packages trouvés dans les GOPATHarborescences avec des noms correspondant aux modèles.

En tant que cas particulier, x/...correspond xainsi que xles sous-répertoires de.
Par exemple, se net/...développe vers netet packages dans ses sous-répertoires.

Si vous conservez vos _test.gofichiers dans un sous-dossier, la go test ./...commande ' ' pourra les récupérer.
Mais:

  • vous devrez préfixer vos variables et fonctions exportées (utilisées dans vos tests) avec le nom de votre package, afin que le fichier de test puisse accéder au contenu exporté du package.
  • vous n'accéderiez pas au contenu non exporté.

Cela étant dit, je préférerais quand même garder le _test.gofichier juste à côté du fichier source principal: il est plus facile à trouver.

VonC
la source
4
Certains pourraient affirmer que le non-accès à des éléments privés est un test normal et meilleur. En ce qui concerne la qualification des symboles publics, vous pouvez toujours importer _ "...".
ddevienne
15

Placez vos tests à côté de votre code dans le même répertoire dans un fichier appelé file_test.gooù «fichier» est le nom du fichier de code source que vous testez. C'est une convention et j'ai trouvé que c'était le meilleur de ma propre expérience.

Si l' go testoutil n'est pas assez automatisé pour vous, vous pouvez consulter GoConvey , qui dispose d'une interface utilisateur Web qui mettra automatiquement à jour et exécutera des tests Go traditionnels ainsi que des tests GoConvey (qui sont basés sur le comportement et sont plus auto-documentés. que les tests Go traditionnels).

Mat
la source
2
GoConvey est génial (et j'attends la nouvelle interface utilisateur avec une grande anticipation). Je l'utilise dans mon projet actuel comme dans github.com/VonC/asciidocgo/blob/master/abstractNode_test.go , par exemple). Cependant, go testpeut également fonctionner pour les sous-dossiers. Voir ma réponse ci
VonC
Tu as raison. En fait, c'est probablement plus pertinent que ma réponse à cette question.
Matt
10

ÉDITÉ

Basé sur la réponse de VonC,

Cette réponse est valable dans go1.11. Pas encore testé dans les goversions supérieures .

Pour ceux d'entre vous qui aiment conserver leurs tests dans un sous-dossier, par exemple test, puis en cours d'exécution

go test ./...

tentera d'exécuter des tests dans chaque dossier, même ceux qui ne contiennent aucun test, ayant ainsi un ?dans le rapport suivant pour les dossiers non test.

Fonctionnement

go test ./.../test

au lieu de cela, ciblera uniquement vos testdossiers, ayant ainsi un rapport propre axé uniquement sur vos dossiers de tests.

MISE EN GARDE

Veuillez noter que l'utilisation de sous-dossiers de test empêchera le calcul du rapport de couverture. La philosophie de go est de laisser les fichiers de test dans les dossiers des packages.

avi.elkharrat
la source
1
Bon conseil, en plus de ma réponse vieille de cinq ans. Vote positif
VonC
chère anna, veuillez expliquer ce qui ne fonctionne pas? et quelle est votre version de go? Qu'essayez-vous de faire? J'ai réalisé par la suite que cette méthode ne permettait pas de calculer la couverture du code, ce qui est dommage. C'est ce que tu veux dire?
avi.elkharrat le
1
go test ./.../testrenvoie go: warning: "./.../test" matched no packages// ne cible pas uniquement les dossiers de test. go version go1.13 darwin / amd64
anna le
1
@Madeo, cela rendrait sens, car golang n'encourage pas la ségrégation des tests et du code. L'anomalie était de l'autoriser dans les versions précédentes.
avi.elkharrat le
1
@ avi.elkharrat et en fait j'ai décidé de ne plus utiliser cette approche, même si j'aimais conserver mes tests dans un package / dossier séparé = (
Madeo
-4

Je ne fais normalement pas de test, mais vous pouvez regrouper votre fichier dans des répertoires et utiliser l'importation comme

import "./models"si est un niveau en sortie
import "../modelssi est un niveau en sortie et un niveau en

Par exemple, pour:
./models/todo.go
./test/todo_test.go

à tester à todo.gopartir todo_test.go, votre importation en todo_test.gosera

import "../models"

Félix Zilla
la source
Cette méthode d'importation du code ne fonctionne que pour les fonctions exposées. Il ne semble pas se comporter comme s'ils étaient dans le même package, même si vous les mettez explicitement dans le même package. Cette solution ne résout donc pas vraiment le problème des tests unitaires.
The Graceful Penguin