You mentioned you have no main() function in your file because it is a test file.
By convention, a file that contains Go test code must end in _test.go
. For example, xyz_test.go
if it contains unit tests for package xyz
. The Go compiler ignores _test.go
files whereas the go test
tool specifically looks for these files.
But still, if your test functions reside within package main
, you need a non-test file for package main
that does contain a main()
function. For example,
-
main.go
contains main()
-
main_test.go
contains unit tests for main.go
(but no main() function).
If you want to write unit tests for a non-main package, put your tests under that package instead of main
. (For example, to write unit tests for code in package xyz
, you would have a file somecode.go
and
a file somecode_test.go
, where both files start with package xyz
and reside in the directory named xyz
.)
(Disclaimer: I don’t know how Ginkgo works, maybe it has its own rules. But if Ginkgo does not integrate well with the standard go test
tool, I would stay away from it.)
A side note on the dot import:
A dot that precedes an import path says that the imported package’s namespace gets merged with the current namespace. For example, if you do this:
import . "fmt"
then you can write
Printf(...)
instead of
fmt.Printf(...)
Usually, this kind of import is a bad idea as it pollutes the current namespace and makes it hard to track down the origin of a given function, type, or variable. (Consider that other people may look at the code, too, and they might be confused by seeing calls to seemingly local functions that are not defined in the current package. Using the package prefix like in fmt.Printf()
does improve code comprehension a lot.)
You mentioned that removing the dot makes the import paths vanish. This happens when an imported package is not used in the current code. In the “fmt” example above, the current package would not contain any calls preceded by “fmt.
” (even though the unprefixed “Printf()
” calls are still there), and so the relevant tool (usually goimports
or goreturns
, which are typically triggered from a Go-aware editor when saving a Go file) removes the seemingly unused imports. (If they are not removed, the compiler would error out, saying this import is not used. This ensures that source code only contains required imports, in order to avoid slowing down compilation needlessly.)