I think the distinction between "unit" and "integration" tests may be a red herring. As a user running tests, generally I want to be able to run “fast” or “smoke” tests (for quick iteration) vs. “slow” or “intensive” tests (to check for regressions and larger-scale statistical properties, and perhaps also to check interactions with particularly large or slow dependencies), without regard to whether those tests are conceptually “unit” or “integration” tests.
(Honestly, I would rather run fast integration tests than slow unit tests!) For that distinction, the testing.Short <https://pkg.go.dev/testing#Short> function (corresponding to `go test -short`) is probably a better fit. On Tuesday, January 4, 2022 at 11:43:32 AM UTC-5 Brian Candler wrote: > On Monday, 3 January 2022 at 20:47:47 UTC davi.marcon...@gmail.com wrote: > >> I believe it behaves this way based on what I've read here >> https://mickey.dev/posts/go-build-tags-testing/ . >> > > Another option would be to put your integration tests into a completely > separate package, and leave unit tests within their original package > (without build constraints). > > Consider that: > - integration tests may involve multiple packages (they are, after all, > testing how the whole system works together) > - integration tests generally treat packages as "black boxes" and are not > expected to make direct access to their internals > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7964bc9c-47ff-42c9-ae97-968e72286957n%40googlegroups.com.
