Any way to exclude testcase(s) from 'go test'?

543 views
Skip to first unread message

xiangd...@gmail.com

unread,
Aug 31, 2020, 11:46:18 PM8/31/20
to golang-nuts
Hi,

I'm looking for a way to exclude one specific testcase (perhaps multiple in the future) from 'go test' and wondering how to define a 'negation' pattern?

For example, how to run all testcases of misc/cgo/test except for a specific one, say Test7978? 

Thanks a lot.

Kurtis Rader

unread,
Aug 31, 2020, 11:56:16 PM8/31/20
to xiangd...@gmail.com, golang-nuts
On Mon, Aug 31, 2020 at 8:46 PM xiangd...@gmail.com <xiangd...@gmail.com> wrote:
I'm looking for a way to exclude one specific testcase (perhaps multiple in the future) from 'go test' and wondering how to define a 'negation' pattern?

For example, how to run all testcases of misc/cgo/test except for a specific one, say Test7978? 

Knowing why you need to do this might elicit better answers but my recommendation would be to put the test in its own test file and add either a `// +build ignore` comment or use a custom build tag and the `-tags` option to optionally enable it. For example, `go test -tags test7978` and `// +build test7978` at the top of the test file you want run only when explicitly enabled.

--
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

xiangd...@arm.com

unread,
Sep 1, 2020, 12:02:51 AM9/1/20
to golang-nuts
Hi Kurtis,

Thanks for replying, background is the github issue 39466 and its potential fix under reviewing, we are trying not to introduce any additional test files and tags but seeking for a change to test command line only,
other opinions are welcome.

Kurtis Rader

unread,
Sep 1, 2020, 12:43:57 AM9/1/20
to xiangd...@arm.com, golang-nuts
On Mon, Aug 31, 2020 at 9:03 PM xiangd...@arm.com <xiangd...@arm.com> wrote:
Thanks for replying, background is the github issue 39466 and its potential fix under reviewing, we are trying not to introduce any additional test files and tags but seeking for a change to test command line only,
other opinions are welcome.

Okay, those links are helpful (and should have been in your first message). I only skimmed each of them but I don't understand why being able to "define a 'negation' pattern" is preferable to using `-tags` to define a "positive pattern" for tests to be run.

xiangd...@gmail.com

unread,
Sep 1, 2020, 2:21:40 AM9/1/20
to golang-nuts
The issue happens at building time of 'go test' for misc/cgo/test, I was expecting 'go test' is powerful enough to skip building a specific case given a negation pattern and without involving tags, but just realized it's a wrong way, 'go test' always builds all dependency stuff.

Now the requirements are:
1. not building Test7978 on arm64 when running the 'dist' test, and
2. minimize the change so that it could be reverted easily when the link issue gets fixed later.

To disable the testing to misc/cgo/test for several 'internal linking' cases on arm64 is an option, but that means other 90 tests are skipped meanwhile.

Kurtis Rader

unread,
Sep 3, 2020, 12:54:08 AM9/3/20
to xiangd...@gmail.com, golang-nuts
On Mon, Aug 31, 2020 at 11:22 PM xiangd...@gmail.com <xiangd...@gmail.com> wrote:
The issue happens at building time of 'go test' for misc/cgo/test, I was expecting 'go test' is powerful enough to skip building a specific case given a negation pattern and without involving tags, but just realized it's a wrong way, 'go test' always builds all dependency stuff.

Now the requirements are:
1. not building Test7978 on arm64 when running the 'dist' test, and
2. minimize the change so that it could be reverted easily when the link issue gets fixed later.

To disable the testing to misc/cgo/test for several 'internal linking' cases on arm64 is an option, but that means other 90 tests are skipped meanwhile.

Can you not leverage the and/or logic of `// +build` comments in the single unit test module affected by this issue to indicate that its tests should not be built or run unless

a) the test is not being run on the "arm64" GOARCH, or

b) the test is being run on the "arm64" GOARCH and the `Test7978` tag was specified.
 
That would result in the test being run most of the time. When the bug you linked to is resolved you simply remove the custom build tag. You seem to have an aversion to using build tags for this problem, which I do not understand, while suggesting that introducing an equivalent mechanism is preferable. i don't understand why.

Reply all
Reply to author
Forward
0 new messages