>if you want to use that package in combination with gomock, you're out of luck

In general, libraries should offer structs, and you should declare your own interfaces with the subset of methods that you require.

This is somewhat messy here because the timer channel is accessed by a field rather than a method, but you could write a struct that embeds time.Timer and adds C() as a method. Then both your wrapped time.Timer and your mock/fake could fulfill your interface.

Though that is true, remember that Go doesn’t support co/contravariance on interface types.

Defining interfaces around existing types works, but quickly falls apart as soon as methods return concrete types. In those cases you need to write more complex wrappers, which is often not worth the hassle.

> The Clock interface also exposes functions like time.After(), which should in my opinion never be used in production code, as they don't support efficient cancelation.

Can you expand on this? I find time.After super useful for time arithmetic in control flow, like checking for expiry, validating leases, etc.

Keep in mind that there are two functions called After(). One is a method of time.Time and can be used to compare timestamps. That’s the one you are likely talking about, and is perfectly fine to use!

I’m talking about the free function After() that’s part of the time package:

https://golang.org/pkg/time/#After

That one can be used to create a channel that triggers after a certain amount of time. The reason you shouldn’t be using that one is because you can’t clean it up before it triggers. This means that any code that bails out early ends up leaking memory temporarily.

Ah, gotcha -- I was thinking of the timestamp comparison method. (Agreed about the other case.)

Not a mock obviously but in the interest of getting things done on schedule I’d suggest running tests in a container with https://github.com/wolfcw/libfaketime and orchestrating edge cases like leap seconds external to the test suite itself.

Interestingly, libfaketime probably won't work in go due to their allergy to using libc on linux. I believe they only use syscalls directly for time-related functionality, meaning that any LD_PRELOAD hack won't work.