3 ms·
Please don't use build tags for integration tests: https://peter.bourgon.org/blog/2021/04/02/dont-use-build-tags-for-integration-tests.html https://peter.bourgo
by maxmcd 3y ago
Please don't use build tags for integration tests: https://peter.bourgon.org/blog/2021/04/02/dont-use-build-tags-for-integration-tests.html https://peter.bourgon.org/blog/2021/04/02/dont-use-build-tag...
Along with the issues listed here you will run into issues with editors not building/linting your tests files because they have build tags that the editor is unaware of.
You can also put the environment variable in a TestMain[1] to cover an entire package of integration tests:
func TestMain(m *testing.M) {
if os.Getenv("RUN_INTEGRATION_TESTS") == "" {
fmt.Println("Skipping integration tests")
return
}
os.Exit(m.Run())
}
[1] https://pkg.go.dev/testing#hdr-Main https://pkg.go.dev/testing#hdr-Main
- eweise 3y agoLooks like more boilerplate to me.
- SPascareli13 3y agoI made this mistake in a project at work...never again.
- mparnisari 3y agoThe mistake of using build tags, or the mistake of not using them?
- SPascareli13 3y agoUsing them.
- Groxx 3y agoPersonally I like putting them in the tests, with t.Skip (frequently further in the code, in whatever sets up test dependencies that makes it an "integration" test, so it's automatically skipped). That way you can blend unit and integration in the same package.
- Scotch3297 3y agoWell, you can configure your editor to lint your test files with build tags and that's the end of the issue. At least on VSCode and Goland you can. I think it's way cleaner to have your integration tests with a build tag rather than this extra piece of code. If you don't have tests all over the place and you are moderately organized with your folder structure, there is no reason why build tags should represent a discoverability issue.