Skip to content
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

testing: want a way to timeout an individual test #10529

nigeltao opened this issue Apr 22, 2015 · 3 comments

testing: want a way to timeout an individual test #10529

nigeltao opened this issue Apr 22, 2015 · 3 comments


Copy link

nigeltao commented Apr 22, 2015

The testing package provides a timeout flag, "if positive, sets an aggregate time limit for all tests", which defaults to zero (no timeout).

In I wanted a timeout for an individual TestFooBar test. It wasn't too hard to implement myself, but it should be part of the standard testing library.

Copy link

minux commented Apr 22, 2015

@robpike robpike added this to the Unplanned milestone May 12, 2015
Copy link

cespare commented Aug 3, 2015

I occasionally write tests for constructs which, if they are buggy, could deadlock. I prefer to have my own timeout because then (a) the user can quickly recognize that the test has failed after only, say, 1 second instead of waiting for a very long timeout (default of 10 minutes), and (b) the message can clearly describe the failure.

For an example of such a test, I think that TestWaitGroup in the stdlib would hang for the default timeout on certain kinds of bugs. (Maybe small timeouts wouldn't be desirable for standard library tests given @minux's point about needing to run on arbitrarily slow machines, but hopefully it's an illustrative example.)

It would be nice to do t.Timeout(time.Second) rather than explicitly making a goroutine in such cases.

@robpike robpike modified the milestones: Go1.6, Unplanned, Go1.6Early Aug 26, 2015
@robpike robpike removed their assignment Sep 29, 2015
Copy link

rsc commented Nov 4, 2015

In CL 8998 your solution depends on moving the work that might never finish into its own goroutine, so that the goroutine running the test can still call t.Fatalf and exit. A plain t.Timeout API is not sufficient here because it would not capture the goroutine issue. One could imagine a more complex API like t.MustRunInTime(time.Duration, func()), but that could just as easily be provided by a helper library. It doesn't need to be in package testing. It's hard for me to see why this must be in package testing.

(In contrast, only package testing knows enough about the aggregate test execution to implement the timeout flag.)

If you want to continue with this, I would suggest resubmitting as a proposal. A design doc will probably be needed.

@rsc rsc modified the milestones: Unplanned, Go1.6Early Nov 4, 2015
@rsc rsc closed this as completed Nov 4, 2015
@golang golang locked and limited conversation to collaborators Nov 4, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

6 participants