This question already has an answer here:
I'm trying to automate running unit tests on an existing Go project. It already has a lot of existing tests which do non-unit test things like contact external services and write to databases. I would like to exclude these test files from the automation using a naming convention. Say the structure of the project is like this:
gopath/
|-package1.go
|-package1_unit_test.go
|-package1_e2e_test.go
|-package2/
|-package2.go
|-package2_unit_test.go
|-package2_e2e_test.go
I can run go test ./... to run all the tests. If I include 'UnitTest' in the names of my unit tests I can run go test ./... -run UnitTest but this still runs the startup code in the e2e tests. I need it to completely ignore those files. Someone suggested running go test $(go list ./... | grep -v /e2e/) but go list outputs directory names, not file names, so that doesn't work.
And yes, ideally the e2e tests should go in a different directory and not rely on the internals of the package but unfortunately that's not how my coworkers wrote them. I'm looking for a quick fix right now!
</div>
You can use build tags to limit builds, including tests, to a certain subset of files: https://dave.cheney.net/2014/09/28/using-build-to-switch-between-debug-and-release
For example, you could put //+build integration at the top of your integration test files, and then those would only be built and executed when you run go test -tags integration.