4 ms·
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)
by Groxx 8mo ago
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.
- deleted 8mo ago[deleted]
- awesome_dude 8mo agoThe compiler will only use _test.go files in the test build - so not an explicit build tag, but a built in one.
- Groxx 8mo agoThat 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. And 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.
- awesome_dude 8mo agoI'm not sure that we are on the same page Are 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?