Best way to use test dependencies in Go but prevent export them

Question

Given a project in Golang (1.14+) which is using test dependencies (like github.com/stretchr/testify) and now assume this project is a public library which can be used by others.

Usually when I now use go mod graph I'll always see this dependency like:

github.com/its-me/[email protected]
github.com/stretchr/[email protected] github.com/davecgh/[email protected]
github.com/stretchr/[email protected] github.com/pmezard/[email protected]
github.com/stretchr/[email protected] github.com/stretchr/[email protected]
github.com/stretchr/[email protected] gopkg.in/[email protected]
gopkg.in/[email protected] gopkg.in/[email protected]

go mod tidy or go mod download also seems to download all the test dependencies from the used lib. But instead of telling everybody to use exclude in their go.mod files is there a way to even prevent this been exported?

Bellda

There is no difference between a "test dependency" and a "dependency". Also dependencies are not "exporter". What problem are you trying to solve and what is the actual question? – Rupiah

If it's an eyesore, move all _test.go to another package run your validations from there. – Hesperian

@Rupiah So far I assumed that there is no difference (following the documentation), but the hope is the last to die. I want to reduce the amount of stuff needs to be downloaded by people by using a public library. I'm (for my self) very often quite annoyed for libs where I have to download (on for example go mod tidy) at first some testing dependencies what I do not use and I do not want to use. – Bellda

@Hesperian your approach is not sexy but sounds plausible and the best option so far. – Bellda

@Bellda Did you find any solution for this problem? I am also facing the same. – Mimicry

@KishanB Not so far, unfortunately. As previously wrote: I try to live with it. :-/ – Bellda

Answer 1

go mod tidy is intended to provide all of the dependencies needed to run go test all. Note that in Go 1.16, go test all will be somewhat less aggressive about transitive dependencies of tests (https://tip.golang.org/doc/go1.16#all-pattern).

However, if your own test itself is using testify, then users of your package will need to download testify in order to run go test all in their own module.

(As colm.anseo notes, if you want you can split out the heavier tests to a separate package, so that when your users run go test all they will not run those tests and will not need to download the source code for those dependencies.)

Note that Go 1.17 adds support for module graph pruning: if your module specifies go 1.17 or higher and a consumer of your module does not use your test dependency in their own module, they will not need to download the source code or go.mod file for that dependency. (And once https://golang.org/issue/44435 is implemented, when they run go mod download it will not download the irrelevant dependency either.)

Chemmy