-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: documentation: testing.T.Parallel resets time #12243
Comments
The reason for resetting the time is that the first time t.Parallel does is block the call until all the other non-parallel tests have completed. You don't want to include those in the time. Perhaps instead it should pause the timer, not reset it. |
That would probably be more reasonable, but would it constitute a backwards-breaking change? |
No, I would not consider s/reset/pause/ a backwards-breaking change. Unless you have a specific scenario in mind? |
I was just thinking of any logic that relies on that functionality - technically backwards-breaking, but very unlikely to occur in practice. |
@joshlf it's not exposed by the testing API, so the only way to rely on the test durations is if you're parsing |
I sent a CL to change from resetting the timer to pausing it. If we do the pause instead, is there any point in documenting it, or does it become sufficiently unsurprising in that case? |
CL https://golang.org/cl/16989 mentions this issue. |
@cespare In that case I agree that it's not an issue. |
Fixed by CL 16989. |
Before, we reset the timer at the end of T.Parallel, which is okay assuming that T.Parallel is the first thing in the test. Snapshot the elapsed time at the beginning of Parallel and include it in the total duration so that any time spent in the test before calling Parallel is reported in the test duration as well. Updates #12243. Change-Id: Ieca553e1f801e16b9b6416463fa8f7fa65425185 Reviewed-on: https://go-review.googlesource.com/16989 Reviewed-by: Russ Cox <rsc@golang.org>
The
testing
package'sT.Parallel
method resets the time of the test so that it's as if the test starts just before the method returns. The reason for doing this is that it's likely the first call made from the testing function. This is reasonable, but I suggest that this behavior be documented. The source is here.The text was updated successfully, but these errors were encountered: