feat: Add T.Context()#77
Conversation
*Context*: Go 1.24 adds a `Context()` method to `testing.TB` that returns a context bound to the current test's lifetime. The context becomes invalid _before_ `T.Cleanup` functions are run. *Details*: This change adds a similar `Context()` method to `rapid.T`, except this context is only valid for the duration of one iteration of a rapid check. *Implementation notes*: This changes `newT` to return a `cancel` function instead of just adding a `cancel` method to `T` to ensure that all callers of `newT` remember to call `cancel`. This also uses IIFEs (immediately-invoked function expressions) in a couple places to rely on well-timed `defer` calls for cleanup instead of manually calling `cancel`. *Future work*: The logic added in this commit will make it relatively straightforward to add a `Cleanup` method (flyingmutant#62).
|
I think the implementation can be greatly simplified by both creating the context and deferring the cancel inside |
|
That makes sense; I was hoping to use the Where Would that work/am I missing anything with it? |
|
Yes, I think something like that should work. Additionally, we can make context creation lazy, only after |
Per GitHub comment, delete the `cancel` return value from newT, instead add a single `cleanup` method. The method is called for cleanup in three places: - checkOnce: this is per property - maybeValue: this is per Custom generator function call - example: this is per Example call Context is now initialized lazily: if there isn't one, it is created.
|
Changed as requested. This is much less disruptive, although To clarify, the behavior we get is:
If this is not the desired behavior, we'll need to delete one or more of the |
engine.go
Outdated
| t.mu.RLock() | ||
| if t.ctx != nil { | ||
| t.mu.RUnlock() | ||
| return t.ctx |
There was a problem hiding this comment.
This is racy: after the unlock t.ctx may already be nil.
There was a problem hiding this comment.
🤦 derp. I had this right the first time around and decided to clean up some local variables for unknown reasons.
|
Thanks, merged! |
* feat: Add T.Context() *Context*: Go 1.24 adds a `Context()` method to `testing.TB` that returns a context bound to the current test's lifetime. The context becomes invalid _before_ `T.Cleanup` functions are run. *Details*: This change adds a similar `Context()` method to `rapid.T`, except this context is only valid for the duration of one iteration of a rapid check. *Implementation notes*: This changes `newT` to return a `cancel` function instead of just adding a `cancel` method to `T` to ensure that all callers of `newT` remember to call `cancel`. This also uses IIFEs (immediately-invoked function expressions) in a couple places to rely on well-timed `defer` calls for cleanup instead of manually calling `cancel`. *Future work*: The logic added in this commit will make it relatively straightforward to add a `Cleanup` method (flyingmutant#62). * lazy init, cleanup in checkOnce, maybeValue, example Per GitHub comment, delete the `cancel` return value from newT, instead add a single `cleanup` method. The method is called for cleanup in three places: - checkOnce: this is per property - maybeValue: this is per Custom generator function call - example: this is per Example call Context is now initialized lazily: if there isn't one, it is created. * fix: data race in t.ctx access
Background:
Go 1.24 adds a
Context()method totesting.TBthat returnsa context bound to the current test's lifetime.
The context becomes invalid before
T.Cleanupfunctions are run.Details:
This change adds a similar
Context()method torapid.T,except this context is only valid for the duration of one iteration
of a rapid check.
For
rapid.Custom, it's only valid for that call to the custom function.Implementation notes:
The context is created lazily on the
*rapid.Tas requested,using the
testing.TB.Contextas the base context if available.A new unexported
cleanupmethod on*rapid.Tis called in strategic placesto cancel the context (if any) when its scope ends.
Future ideas:
The
cleanupfunction added here can be expanded in the futurein support of a
Cleanupmethod (#62).