Go "go test -count=1" Cache Bypass - Fix Cached Test Results in CI

By Kaveh Alemi·Latchkey

go test caches passing results and prints (cached) when inputs are unchanged. In CI that can mask a failure - a test that depends on something outside Go’s cache key (a clock, an env var, an external service) shows a stale (cached) PASS. -count=1 is the supported way to force a real re-run.

What this error means

A test prints ok pkg (cached) and the suite passes, but the test never actually ran this time - so a regression that depends on un-tracked inputs slips through. Adding -count=1 makes the same package re-execute.

ok      github.com/org/app/store      (cached)
# the test did not run; a change outside Go's cache key was not retested

Common causes

Go served a cached passing result

When the package’s inputs (source, env vars Go tracks, command line) are unchanged, go test reuses the cached PASS instead of running the test.

A test depends on inputs outside the cache key

A test that reads the wall clock, an untracked env var, or an external service is not invalidated by Go’s cache key, so a cached PASS can be stale.

How to fix it

Force a real run with -count=1

The idiomatic cache bypass is -count=1, which re-executes every selected test.

go test -count=1 ./...

Clear the cache when results look stale

go clean -testcache
go test ./...

Make tests depend only on tracked inputs

1. Inject time/IO so tests are deterministic and cache-safe.
2. Avoid reading untracked global state inside tests.
3. Use -count=1 in CI when external dependencies are unavoidable.

How to prevent it

• Run CI tests with -count=1 so caching never hides a failure.
• Keep tests deterministic and dependent only on tracked inputs.
• Use go clean -testcache to recover from stale results.

Frequently asked questions

Related guides

References

• Go documentation
• GitHub Actions documentation