Multiple tagging to a single test case

[shynamatharu (Shyna)]

Hi, is it possible to have a // +build integration or // +build smoke like tags for each test case instead of per file? Suppose a file contains 20 test cases, 10 of them will be part of only integration test, 5 of them only smoke test and rest 5 will be both smoke and integration test?

[shynamatharu (Shyna)]

@petrus

A build constraint, also known as a build tag, is a line comment that begins

// +build

that lists the conditions under which a file should be included in the package. Build constraints may also be part of a file’s name (for example, source_windows.go will only be included if the target operating system is windows).

Hi @petrus,
Thanks for reply, but this is again per file basis. I need to differentiate on per test case basis like

//------------These are in same file -----------------------------

// @smoke @integration
func TestFunc1(t *testing.T) {
   ...
    ...
}
// @smoke
func TestFunc2(t *testing.T) {
    ...
    ...
}
// @integration
func TestFunc3(t *testing.T) {
  ...
    ...
}

So, you see, below should be how test cases should run with go test command which may be modified to run custom test cases, if possible as:
TestFunc1 —>. go test —> both integration and smoke tests,
TestFunc2 —>. go test -tags=smoke —> should only be part of smoke test
TestFunc3. —>. go test -tags=integration —> should only be part of integration test

PS. In order to reduce code bloating/repetition, same test cases should not be part of different files so not going with an option of creating separate file for smoke_test.go/integration_test.go

Please let me know if this is possible?

[ncw (Nick Craig-Wood)]

@shynamatharu

Please let me know if this is possible

I don’t think so. Build tags are deliberately per file and you can’t read them at runtime.

You could have two files which just define a constant and then use that.

I prefer the technique of adding flags to the test though.

So use the flags module to add a “-smoke” flag and use it to t.Skip() tests you don’t want.

You can use an env var also.