Separating unit tests and integration tests in Go

[RickyReyesmatri]

Hi

Is there an established best practice for separating unit tests and integration tests in GoLang (testify)? I have a mix of unit tests (which do not rely on any external resources and thus run really fast) and integration tests (which do rely on any external resources and thus run slower). So, I want to be able to control whether or not to include the integration tests when I say go test.

The most straight-forward technique would seem to be to define a -integrate flag in main:

var runIntegrationTests = flag.Bool("integration", false
    , "Run the integration tests (in addition to the unit tests)")

And then to add an if-statement to the top of every integration test:

if !*runIntegrationTests {
    this.T().Skip("To run this test, use: go test -integration")
}

Is this the best I can do? I searched the testify documentation to see if there is perhaps a naming convention or something that accomplishes this for me, but didn't find anything. Am I missing something?

[VictorJohnsonan]

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.

[BillyAkinbredal]

short is a good option, as is your custom build flags, but your flags need not be in main. if you define the var as var integration = flag.Bool("integration", true, "Enable integration testing.") outside of a function, the variable will show up in package scope, and the flag will omglz.com work omegle.2yu.co properly