在Go中使用测试依赖项的最佳方法，但防止导出它们

Question

给定Golang (1.14+)中的一个项目，该项目使用的是测试依赖项(如github.com/stretchr/ test )，现在假设该项目是一个可供其他人使用的公共库。

通常，当我现在使用go mod graph时，我总是会看到这样的依赖：

github.com/its-me/my-great-library@1.0.0
github.com/stretchr/testify@v1.6.1 github.com/davecgh/go-spew@v1.1.0
github.com/stretchr/testify@v1.6.1 github.com/pmezard/go-difflib@v1.0.0
github.com/stretchr/testify@v1.6.1 github.com/stretchr/objx@v0.1.0
github.com/stretchr/testify@v1.6.1 gopkg.in/yaml.v3@v3.0.0-20200313102051-9f266ea9e77c
gopkg.in/yaml.v3@v3.0.0-20200313102051-9f266ea9e77c gopkg.in/check.v1@v0.0.0-20161208181325-20d25e280405

go mod tidy或go mod download似乎也从使用的库下载了所有的测试依赖项。但是，与其告诉每个人在他们的exclude文件中使用go.mod，还有什么方法可以防止这种情况被导出呢？

Answer 1

go mod tidy旨在提供运行go test all所需的所有依赖项。请注意，在Go 1.16中，go test all对于测试的传递依赖项(https://tip.golang.org/doc/go1.16#all-pattern)的侵略性要小一些。

但是，如果您自己的测试本身正在使用testify，那么您的包的用户将需要下载testify，以便在他们自己的模块中运行go test all。

(正如colm.anseo所指出的，如果需要，可以将较重的测试拆分到单独的包中，这样当用户运行go test all时，他们就不会运行这些测试，并且不需要为这些依赖项下载源代码。)

注意，Go 1.17增加了对模块图剪枝的支持:如果您的模块指定了go 1.17或更高版本，并且模块的使用者没有在自己的模块中使用您的测试依赖项，他们将不需要下载该依赖项的源代码或go.mod文件。(一旦实现了https://golang.org/issue/44435，当他们运行go mod download时，也不会下载无关的依赖项。)