panic(nil) in a test results in it immediately passing

[sclevine]

This behavior was identical to that of the built-in testing package, but it changed over a year ago: golang/go#6546

Relevant sections:

• internal/leafnodes/runner.go#L97
• internal/leafnodes/runner.go#L72
• ginkgo_dsl.go#L248

This makes it easy to unknowingly skip assertions, so it seems pretty dangerous. That said, fixing it may break some people's test suites.

(CC @rosenhouse)

[onsi]

Yes we should fix this, even if it breaks existing suites (which are likely incorrectly passing)

Do you think you have the bandwidth for a PR?

[sclevine]

Yep, happy to help!

[sclevine]

Done. Let me know what you think.

A few points:

1. Some people may be using panic(nil) intentionally. It could be considered a convenient (although highly confusing) way of short-circuiting the rest of a test.
2. I don't think it's possible to fix GinkgoRecover() without changing its interface.

[rosenhouse]

is this preferable to a more explicit, hardcoded error like test executed panic(nil) or runtime.Goexit in the standard library?

[rosenhouse]

Ok, it's getting wrapped with the "Test Panicked" message in failer.go. That looks good.

[sclevine]

I went back and forth on whether this message should be more verbose. On one hand, <nil> is consistent with how Ginkgo normally behaves when you panic (and as you mentioned, Ginkgo already indicates that the test panicked). On the other hand, you'll get this same message when you call runtime.Goexit(), and that could be confusing.

[onsi]

yep not much to be done with GinkgoRecover() - it's typically run in a spawned Goroutine and it's impossible to recover a panic in one Goroutine from another so there's no way to play the finished trick without changing the external interface.