I know the above code is buggy because its calling t.Error from a goroutine that lasts longer than the test goroutine and so t.Error will panic in t.Fail. However, the original test was complex and no one saw this coming.
The issue I was having is that the error call is never reported. t.Error panics and then this is recovered and logged but the individual test within which this happened is not marked as failed. Only the parent test is marked as failed. This made the test very hard to debug as there would be no line on which the failure occurred.
So if you run this code, you'll get:
$ go test
--- FAIL: TestFoo (0.00s)
FAIL github.com/nhooyr/scratch 1.006s
Which made me scratch my head for quite a while.
I want to repeat that I know this is a violation of the docs and so maybe shouldn't be fixed but at the same time, I think that it would be much easier to detect such failures if t.Fail reported the line number at which it was called. This would have made the above issue easy to debug and I can imagine a line number reported by t.Fail to be useful in other scenarios as well.
The text was updated successfully, but these errors were encountered:
changed the title
t.Fail should report the line on which the failure occurredJul 31, 2018
It would be nice to do better here but what you seem to suggest seems impossible. At the time that the goroutine calls t.Error the subtest started by t.Run is complete and has passed. There isn't any way for us to retroactively decide that it has failed.
But it does seem possible to have t.Fail detect that the test has completed, and to act differently in that case.