Command `go test` without build constraints does not work

[Davi Marcondes Moreira]

Hi, happy new year y'all! I just want to make sure of something, probably it's just a boolean question (yes/no).

I've been working on a project where all test files are declaring a build constraint at the first line, like the ones below:

// +build unit

or

// +build integration

When I run the tests with `go test ./...`, I receive the message that there are no test files found; but, if I run `go test -tags integration,unit ./...`, then the tests are finally executed. Therefore, if I want to run the test base, I have to inform these constraints.

My question is: is it correct to assume that, in a test base where all files are using build constraints, we have to inform these tags when running tests, and if don't, the command cannot find any test files, despite the fact if they are executable or not, is that right?

I've read the docs for https://pkg.go.dev/go/build and https://pkg.go.dev/cmd/go#hdr-Build_constraints but I couldn't find anything explicitly related to test execution. I believe it behaves this way based on what I've read here https://mickey.dev/posts/go-build-tags-testing/ .

Thanks in advance!

[Jan Mercl]

On Mon, Jan 3, 2022 at 9:48 PM Davi Marcondes Moreira
<davi.marcon...@gmail.com> wrote:

> I've read the docs for https://pkg.go.dev/go/build and https://pkg.go.dev/cmd/go#hdr-Build_constraints but I couldn't find anything explicitly related to test execution.

It is not related to test execution. The build system does not
consider files with unsatisfied build constraints. If all test files
(*_test.go) are excluded by the build system the result is thus that
there are no test files. Hence the error message because it would be
bad if running `go test` with no test files succeeded silently.

[Brian Candler]

On Monday, 3 January 2022 at 20:47:47 UTC davi.marcon...@gmail.com wrote:

I believe it behaves this way based on what I've read here https://mickey.dev/posts/go-build-tags-testing/ .

Another option would be to put your integration tests into a completely separate package, and leave unit tests within their original package (without build constraints).

Consider that:

- integration tests may involve multiple packages (they are, after all, testing how the whole system works together)

- integration tests generally treat packages as "black boxes" and are not expected to make direct access to their internals 

[Bryan C. Mills]

I think the distinction between "unit" and "integration" tests may be a red herring. As a user running tests, generally I want to be able to run “fast” or “smoke” tests (for quick iteration) vs. “slow” or “intensive” tests (to check for regressions and larger-scale statistical properties, and perhaps also to check interactions with particularly large or slow dependencies), without regard to whether those tests are conceptually “unit” or “integration” tests.

(Honestly, I would rather run fast integration tests than slow unit tests!)

For that distinction, the testing.Short function (corresponding to `go test -short`) is probably a better fit.