I suspect that using a build tag (say `test`) and two function definitions (one that directly calls `time.Now()` and one test-only one that uses a mutable var) will optimize out to zero cost in the non-test case - last I fiddled with that, it was pretty good at consistently inlining trivial wrapper funcs like that.
replyThe compiler will only use _test.go files in the test build - so not an explicit build tag, but a built in one.
replyThat doesn't give you a way to exclude conflicting code, unfortunately, so you can't provide an optimal one for non-test code with it.
replyAnd stuff like `func SetTime(...)` in a _test.go file only works for tests in that same package, because other packages don't compile that _test.go and won't have that function defined.
I'm not sure that we are on the same page
replyAre you saying that you want multiple build tagged files each with a different implementation of the function, all in the same package? (eg. windows, linux, arm)
I mean, the example given by the GP is two implementations in the same package, the standard library version is used in the prod file and the test implementation in the test files - the _test.go is the (implicit) build tag
Or do you have something else in mind?
deleted
reply