From this stackoverflow answer:
@Ainar-G suggests several great patterns to separate tests.
This set of Go practices from SoundCloud recommends using build tags (described in the "Build Constraints" section of the build package) to select which tests to run:
Write an integration_test.go, and give it a build tag of integration. Define (global) flags for things like service addresses and connect strings, and use them in your tests.
// +build integration var fooAddr = flag.String(...) func TestToo(t *testing.T) { f, err := foo.Connect(*fooAddr) // ... }
go test takes build tags just like go build, so you can call
go test -tags=integration
. It also synthesizes a package main which calls flag.Parse, so any flags declared and visible will be processed and available to your tests.
As a similar option, you could also have integration tests run by default by using a build condition // +build !unit
, and then disable them on demand by running go test -tags=unit
.
@adamc comments:
For anyone else attempting to use build tags, it's important that the // +build test
comment is the first line in your file, and that you include a blank line after the comment, otherwise the -tags
command will ignore the directive.
Also, the tag used in the build comment cannot have a dash, although underscores are allowed. For example, // +build unit-tests
will not work, whereas // +build unit_tests
will.
From this stackoverflow question answer.
- Unit tests use the normal
TestX
name - Integration tests use
Test_X
I created shell scripts (utest.sh
/itest.sh
) to run either of those.
- For unit tests
go test -run="^(Test|Benchmark)[^_](.*)"
- For integration tests
go test -run"^(Test|Benchmark)_(.*)"
- Run both using the normal
go test