I have a public function F in my package, which first calls GetX then calls FilterY, then return the filtered results.
Both GetX and FilterY are public, as I want thorough unit tests for them. But, they serve no purpose, they are unlikely to be called alone by any users of my package. Only F is going to be called, thus making GetX and FilterY good candidates for private functions.
Should I keep these 2 methods public just for the sake of unit tests ? Bear in mind there is some complex logic in FilterY so it needs a lot of unit test cases.
If your *_test.go files for the package are in the same directory with the package source code then they are part of the package itself, and they can access all functions defined in the package whether public or private. Look at the go packages themselves in go/src.
You mean placing the tests in the same package as the code. This looks like a bad idea long term, as I do not want the importers of my package unknowingly import any sqlmock or whatever else I import solely for testing.
I call BS on this. Namely I have a file a.go and a_test.go, both of them having the first line package mypackage. If I define a non test function inside a_test.go, I am allowed to call it from a.go.
I therefore doubt then that it will not import the whole imported packages from a_test.go, every time I import mypackage.
So call it as you want, until you have proven that a function from a _test.go file leaks, I trust in the documentation. And if you can indeed prove that there is a leak, then its worth a bug report, such that either the compiler or the documentation can be fixed.
When the package is compiled to its .a file for linking _test.go files are ignored. Look at the regexp package in the go src directory: https://golang.org/src/regexp/.
If I copy your files and try to compile them, it fails:
$ go build .
# _/tmp/tmp.Z4s5MMdPvS
./a.go:4:4: undefined: printSomething
And for the sake of completeness and comparability:
$ go version
go version go1.14.6 linux/amd64
This behaviour is reproducible from go 1.12 through 1.15:
$ for i in 12 13 14; do nix run nixos.go_1_$i -c go version; nix run nixos.go_1_$i -c go build .; done
go version go1.12.17 linux/amd64
# _/tmp/tmp.Z4s5MMdPvS
./a.go:4:4: undefined: printSomething
go version go1.13.12 linux/amd64
# _/tmp/tmp.Z4s5MMdPvS
./a.go:4:4: undefined: printSomething
go version go1.14.4 linux/amd64
# _/tmp/tmp.Z4s5MMdPvS
./a.go:4:4: undefined: printSomething
$ nix run nixpkgs.go_1_15 -c go version; nix run nixpkgs.go_1_15 -c go build .
go version go1.15beta1 linux/amd64
# _/tmp/tmp.Z4s5MMdPvS
./a.go:4:4: undefined: printSomething
Shouldnāt make a difference, but have you tried to actually build the code using the compiler or did you just trust in your IDE not complaining?
Also, compiling the program above in ātest modeā would actually be possible, as tests werenāt possible if you would ignore test files then as wellā¦