Tests Golang dans le sous-répertoire

Question

Je veux créer un package en Go avec les tests et les exemples du package en tant que sous-répertoires pour 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 est-ce juste une convention ?

Answer 1

Notez que vous peut courir go test "de manière récursive" : vous devez listez tous les paquets que vous voulez tester .

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

go test ./...

Le ' ./... La notation ' est décrite dans la section " Description des listes de colis " de la " commande go " :

Un chemin d'importation est un modèle s'il comprend un ou plusieurs " ... "Chacun d'entre eux peut 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 paquets trouvés dans le répertoire GOPATH des arbres dont les noms correspondent aux modèles.

Un cas particulier, x/... correspondances x ainsi que x dans les sous-répertoires.
Par exemple, net/... s'étend à net et les paquets dans ses sous-répertoires.

---

Si vous gardez votre _test.go dans un sous-dossier, les fichiers ' go test ./... Le commandement sera en mesure de les récupérer.
Mais.. :

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

Ceci étant dit, je préférerais tout de même conserver la _test.go à côté du fichier source principal : il est plus facile à trouver.

---

2022 : Pour la couverture des codes :

go test -coverpkg=./... ./...

Voir " Comment tracer la couverture des tests Go dans le temps " de Frédéric G. MARAND y fgmarand/gocoverstats pour produire des statistiques globales sur la couverture de l'intégration CI des projets Go.

En outre, go-cover-treemap.io est amusant.

---

Mars 2023 : Comme indiqué dans le document " Couverture du code pour les tests d'intégration de Go " :

Avec la version 1.20, l'outil de couverture de Go n'est plus limité aux tests de paquets, mais prend en charge la collecte de profils à partir de tests d'intégration plus importants.

Ejemplo:

$ go build -cover -o myprogram.exe myprogram.go
$ mkdir somedata
$ GOCOVERDIR=somedata ./myprogram.exe
I say "Hello, world." and "see ya"
$ ls somedata
covcounters.c6de772f99010ef5925877a7b05db4cc.2424989.1670252383678349347
covmeta.c6de772f99010ef5925877a7b05db4cc

Véase Couverture Go 1.20 .

---

Comme l'a noté kbolino en les commentaires :

Vous pouvez placer vos tests dans un paquet séparé sans les placer dans un répertoire séparé.
Les fichiers de test pour le paquet foo peuvent se trouver dans le paquet foo_test et se trouve toujours dans le même répertoire, tout en étant également pas avoir accès aux membres non exportés (privés) du paquet foo .

Answer 2

MODIFIÉ

Construit à partir de la réponse de VonC,

Cette réponse est valable en go1.11 . Pas encore testé dans la partie supérieure go versions.

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

go test ./...

tentera d'exécuter des tests dans tous dossier, même ceux qui ne contiennent pas de test, ce qui permet d'avoir une ? dans le rapport suivant pour les dossiers non testés.

La course à pied

go test ./.../test

au lieu de cela, il ne ciblera que votre test ce qui permet d'avoir un rapport propre, centré uniquement sur les dossiers de tests.

ATTENTION

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 paquets.

Answer 3

Placez vos tests à côté de votre code dans le même répertoire, dans un fichier appelé file_test.go où "file" est le nom du fichier de code source que vous testez. Il s'agit d'une convention et j'ai constaté qu'elle était la meilleure dans ma propre expérience.

Si le go test n'est pas assez automatisé pour vous, vous pouvez utiliser l'outil GoConvey qui dispose d'une interface web qui met à jour et exécute automatiquement les tests Go traditionnels ainsi que les tests GoConvey (qui sont basés sur le comportement et sont plus auto-documentés que les tests Go traditionnels).

Answer 4

Normalement, je ne fais pas de test, mais vous pouvez regrouper vos fichiers dans des répertoires et utiliser l'importation comme suit

import "./models" si c'est un niveau en dehors
import "../models si c'est un niveau en dehors et un niveau en dedans

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

pour tester todo.go de todo_test.go , votre importation dans le todo_test.go sera

import "../models"