-
Notifications
You must be signed in to change notification settings - Fork 11
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
feat(test): add mock clock API #18
Conversation
@Stebalien PTAL |
Next step will be to use this mock clock in all the test here that currently do |
Yes, let's land this first please. |
@marten-seemann @Stebalien It seems running the tests many times ( |
Even removing the overwrite check, running two tests in a row (is it really sequential?) still fails locally:
So it seems I'm clearly missing something of how multiple runs of same test share context that I'll need to look closer into. |
Did current tests pass with |
I think anything that is run in the same If this is confirmed then the expectation of #17 (comment) is clearly unmet and we should re-discuss in the issue how is the mock clock going to be used. |
Yeah, we're definitely sharing the sweeper across tests. Blocking on #17 (comment). |
|
Having race issues with the swapping, will try some more this approach (with more care of stopping goroutines first) and attempt the alternative if I can't make progress here. |
f04ec7a
to
9725a73
Compare
9725a73
to
f34d616
Compare
Added a stop signal when swapping sweepers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This probably works, but being able to "stop" adds complexity.
You encountered a race because the globalSweeper
is by-value. If we make it by-reference, we should be able to replace it without interfering with the previous sweeper (which will die on its own).
// SetClock puts a global clock in place for testing purposes only. | ||
// It should be called only once and before using any of the Meter or | ||
// MeterRegistry APIs of this package and should be restored with | ||
// RestoreClock after the test. | ||
func SetClock(clock clock.Clock) { | ||
globalSweeper.stop() | ||
globalSweeper = sweeper{} | ||
globalSweeper.clock = clock | ||
} | ||
|
||
func RestoreClock() { | ||
globalSweeper.stop() | ||
globalSweeper = sweeper{} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are testing functions and don't need to be exported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea would be to use this in libp2p/go-libp2p-core#267 so I think we still want to export this, or something similar to it.
mockClock.Add(40 * time.Millisecond) | ||
} | ||
actual := m.Snapshot() | ||
checkApproxEq(t, actual.Rate, 25000, 100) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I've said this before, but there's no need for approximations. We're using a mock clock, so timing is precise, and so should be the measurement.
I'm getting the impression that this PR is moving in the wrong direction. |
Co-authored-by: Steven Allen <[email protected]>
That makes sense. |
@marten-seemann Your call. This PR is already passing and I'm aligned with Steven's input, so I'm not sure which wrong direction has this taken. The error margin comment is valid but it's not central to the mock clock implementation (but how we leverage it later), so I prioritized fixing the data race which was the blocker here. |
Went with a more specialized
UseMockClock
API to clearly signal this is for tests and not something you normally mess with but can revert to the more generalSetClock
if preferred.Closes #17.