Executing the unit tests locally allows us to execute these tests frequently without touching the actual REST API. This is particularly useful when we’re working on a disconnected environment or when using third-party APIs. It also provides a controlled and repeatable environment where we can test different conditions that may not be possible with the actual API, such as error conditions.

But this approach has a downside. If we miss a detail about the API or if the API changes, the application might not work properly, but the local tests will make us think it does. To overcome this challenge, we’ll run an integration test that connects to the actual API as the last step in our testing process. To ensure that this test doesn’t run all the time, we’ll think of a build constraint as a condition that defines whether to include a file when building or testing the application.

Creating the cmd/integration_test.go file

For this example, we’ll create a new test file cmd/integration_test.go with the build constraint integration. This prevents Go from selecting this file and consequently running this test unless we explicitly use the parameter -tags integration when running the tests.

We create and edit a new file called cmd/integration_test.go. We define the build constraint as a comment at the top of the file, before the package definition. We include the package definition as well:

Get hands-on with 1200+ tech skills courses.