The accepted proposal https://github.com/golang/go/issues/36532 added a Context method to testing.T, which is great, but I can think of two straightforward ways to improve its usefulness further:
Expose T.Deadline() as the deadline for the context. There are (hopefully rare) cases where something needs to propagate deadline information to something that isn't go, e.g. a subprocess, where simple cancelation may not be sufficient. Even in cases where the final consumer of the context is go, it's helpful for e.g. logging to be able to distinguish between a context cancelled due to a timeout vs. cancelled for some other reason. This should be as simple as swapping out context.WithCancel for context.WithDeadline where appropriate.
Create a trace.Task named for the test. When running a trace or benchmark with -trace, it can be handy to be able to track back regions to specific tests. This, too, is fairly low-cost given that the testing package already depends on runtime/trace.
Proposal Details
The accepted proposal https://github.com/golang/go/issues/36532 added a Context method to
testing.T
, which is great, but I can think of two straightforward ways to improve its usefulness further:T.Deadline()
as the deadline for the context. There are (hopefully rare) cases where something needs to propagate deadline information to something that isn't go, e.g. a subprocess, where simple cancelation may not be sufficient. Even in cases where the final consumer of the context is go, it's helpful for e.g. logging to be able to distinguish between a context cancelled due to a timeout vs. cancelled for some other reason. This should be as simple as swapping outcontext.WithCancel
forcontext.WithDeadline
where appropriate.trace.Task
named for the test. When running a trace or benchmark with-trace
, it can be handy to be able to track back regions to specific tests. This, too, is fairly low-cost given that thetesting
package already depends onruntime/trace
.