3efa7bdcc2
This fixes some rare test flakes caused by a data race inherent in the way we use `assert.Eventually()` with extra variables for followup assertions. This function is tricky to use correctly because it runs the passed function in a separate goroutine, and you have no guarantee that any shared variables are in a coherent state when the `assert.Eventually()` call returns. Even if you add manual mutexes, it's tricky to get the semantics right. This has been a recurring pain point and the cause of several test flakes. This change introduces a new `library.RequireEventually()` that works by internally constructing a per-loop `*require.Assertions` and running everything on a single goroutine (using `wait.PollImmediate()`). This makes it very easy to write eventual assertions. Signed-off-by: Matt Moyer <moyerm@vmware.com> |
||
|---|---|---|
| .. | ||
| browsertest | ||
| access.go | ||
| assertions.go | ||
| cli.go | ||
| client.go | ||
| env.go | ||
| iotest.go | ||
| iplookup.go | ||
| iplookup_go1.14.go | ||
| skip.go | ||
| spew.go | ||