Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

testing: feature request: mechanism to disable test caching for specific unit tests #34635

Closed
dudleycodes opened this issue Oct 1, 2019 · 2 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@dudleycodes
Copy link

dudleycodes commented Oct 1, 2019

What version of Go are you using (go version)?

$ go version
go version go1.13.1 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/{name}/Library/Caches/go-build"
GOENV="/Users/{name}/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/{name}/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13.1/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rv/cjpwdbp50p573x7q0ggx9bjc0000gp/T/go-build190894529=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I'm writing integration tests using the testing package that are triggered via build tags; e.g.:

// +build integration

package myservice

func Test123(t *testing.T) {
        ....
}

Due to the nature of the integration tests their results should never be cached as the systems they are integrating against are always changing.

What did you expect to see?

A mechanism to disable caching for specific test functions.

What did you see instead?

Mechanisms for either clearing the cache for all tests or disabling the cache for all test.

Workaround

Can currently workaround this issues by running tests twice:

  1. Run all unit tests, which the cache should be maintained for, via go test ./...
  2. Run integration test by using the build tag and combining with -count=1 -run=....

This workaround requires that all tests that should never be cached have a regex pattern that be be used; forcing all these test to include the phrase NoCache or something else. These tests would also still need to be protected by requiring a build tag to prevent them from being run in step 1.

Proposal

Add a NoCache() method to the testing.T struct that would disable the specific method from being cached.

// +build integration

package myservice

func Test123(t *testing.T) {
        t.NoCache()
        ....
}
@ALTree
Copy link
Member

ALTree commented Oct 1, 2019

Thanks for the request. This is a dup of #23799.

@ianlancetaylor ianlancetaylor changed the title Feature Request: Mechanism to disable test caching for specific unit tests testing: feature request: mechanism to disable test caching for specific unit tests Oct 1, 2019
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 1, 2019
@ianlancetaylor ianlancetaylor added this to the Go1.14 milestone Oct 1, 2019
@ianlancetaylor
Copy link
Contributor

Thanks. Closing as a dup. Please comment over on #23799.

@golang golang locked and limited conversation to collaborators Sep 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants