-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: Document that T.Log and friends should not be invoked after the end of the test #40343
Comments
/cc @mpvl |
I don't think the docs for this should say anything about the race detector. In some sense it seems obvious to me that you should not be able to log information after the test ends. And indeed there is an explicit panic for that case (https://golang.org/src/testing/testing.go#L721). But although it seems obvious I think it would be OK to briefly document that requirement in the various Log methods. |
@ianlancetaylor what about panicking more than causing triggering this race condition? |
@slinkydeveloper I'm sorry, I don't understand the question. |
So I experienced this issue because https://golang.org/src/testing/testing.go?s=25276:25317#L1025 writes at same time than https://golang.org/src/testing/testing.go?s=25276:25317#L716 reads, but the write at L1025 doesn't lock the |
If that's not possible, then I think we should clearly doc this behaviour, so people understands why they see a race in the testing code |
There is no try-lock for I've already agreed that we can add some brief documentation. I just don't think the documentation should mention the race detector, because that is irrelevant. |
Try to run this test: import (
"testing"
"time"
)
func TestTestRace(t *testing.T) {
t.Run("aaa", func(t *testing.T) {
go func() {
for true {
t.Logf("aaa")
}
}()
time.Sleep(1 * time.Second)
})
t.Run("bbb", func(t *testing.T) {
t.Logf("bbb")
})
} And you'll get this race from the race detector:
And that race just sounds weird to me because i don't get any enforcements/clear error messages that I'm effectively doing something wrong. Maybe is the testing.T code itself that is wrong and should have a lock here? https://golang.org/src/testing/testing.go?s=25276:25317#L1025 |
Note that if I change your test to package x_test
import (
"testing"
"time"
)
func TestTestRace(t *testing.T) {
t.Run("aaa", func(t *testing.T) {
go func() {
for true {
t.Logf("aaa")
}
}()
time.Sleep(1 * time.Second)
})
t.Run("bbb", func(t *testing.T) {
t.Logf("bbb")
})
}
func TestWait(t *testing.T) {
time.Sleep(5 * time.Second)
} then I get
In other words, the reason that you don't see a failure with your test is that the test program exits before the problem is detected. That said, I'm OK with detecting the problem more reliably if there is some safe way to do so. |
(To be clear, I see that panic shown above when not using |
That's strange, in my use case I have tons of tests running in the same process (most of them are subtests) and none panics, but they randomly detect the data race https://prow.knative.dev/view/gs/knative-prow/pr-logs/pull/knative_eventing/3679/pull-knative-eventing-integration-tests/1287757317411966980 |
For this, check for race condition detection warnings: Regularly run your tests with race condition detection (go test -race) to identify potential problems. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I learnt, while using testing tools, that you cannot invoke
t.Logf
and similar aftert
is done: https://golang.org/src/testing/testing.go?s=25276:25317#L1025What did you expect to see?
Some doc in all logging methods of
T
, like https://golang.org/pkg/testing/#T.Log, explaining this behaviour:What did you see instead?
Nothing documented so far
The text was updated successfully, but these errors were encountered: