Note that you can run go test “recursively”: you need to list all the packages you want to test.
If you are in the root folder of your Go project, type:
go test ./...
The ‘./...‘ notation is described in the section “Description of package lists” of the “command go“:
An import path is a pattern if it includes one or more “
...” wildcards, each of which can match any string, including the empty string and strings containing slashes.Such a pattern expands to all package directories found in the
GOPATHtrees with names matching the patterns.As a special case,
x/...matchesxas well asx‘s subdirectories.
For example,net/...expands tonetand packages in its subdirectories.
If you keep your _test.go files in a subfolder, the ‘go test ./...‘ command will be able to pick them up.
But:
- you will need to prefix your exported variables and functions (used in your tests) with the name of your package, in order for the test file to be able to access the package exported content.
- you wouldn’t access non-exported content.
That being said, I would still prefer keep the _test.go file right beside the main source file: it is easier to find.
For code coverage:
go test -coverpkg=./... ./...
See “How to plot Go test coverage over time” from Frédéric G. MARAND and fgmarand/gocoverstats to produce aggregate coverage statistics for CI integration of Go projects.
Also go-cover-treemap.io is fun.