Proposal: add context.Context objects to testing.T EDIT: and testing.M

[Lucretiel]

Proposal: add a test-local Context object to testing.T objects. The object would be accessible like this:

func TestSomething(t *testing.T) {
    ctx = t.Context()
    ...
}

It would be cancelled at the end of the test. This would allow tests involving network calls, parallel goroutines, or other blocking code to use the context to cancel all the background stuff in the event the test fails an assertion early with FailNow or something similar.

It should be a fairly straightforward feature, so if there's interest I can create a Pull Request when I have time.

[minux]

I think this has already been done, no? https://tip.golang.org/pkg/testing/#T.Context

[Lucretiel]

Right you are! I wasn't looking at tip.. Ty!

[bradfitz]

@Lucretiel, what was your motivation for wanting this, out of curiosity?

[Lucretiel]

I have an internal RpcClient struct that uses a background goroutine to keep the connection pool up to date– closing idle connections, performing new host discovery, and so on. We use a Context to tell this object when to close that goroutine. It's fairly straightforward to do WithCancel and defer cancel(), but it seems like Context is becoming the de-facto mechanism to "signal a collection of goroutines to stop working and shut down," so it'd be nice to have it provided by test to prevent duplicating those lines.

Originally, my request was to add the feature to gocheck (go-check/check#88). In particular, I thought it'd be nice to have a single, suite-level Context, as well as individual test-level Contexts. Since gocheck is based on testing, I figured I'd request it here, too.

Actually, since I just discovered that testing also supports suite-level fixtures through TestMain, I wonder if there would be any interest in adding a Context to testing.M, and having the individual testing contexts be its children?

[bradfitz]

This was already added to Go master (to-be Go 1.8). There are concerns about it, though. Whether to keep it is being tracked in #18199.

I'm going to close this bug again as it's a dup of #16221 and #18199

[Lucretiel]

Sounds good. Ty for the update.