Skip to content

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

Merged
onsi merged 1 commit into
onsi:masterfrom
sclevine:fail-on-panic-nil
Jun 10, 2015
Merged

panic(nil) in a test results in it immediately passing#167
onsi merged 1 commit into
onsi:masterfrom
sclevine:fail-on-panic-nil

Conversation

@sclevine

@sclevine sclevine commented Jun 9, 2015

Copy link
Copy Markdown
Contributor

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

Relevant sections:

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

onsi commented Jun 9, 2015

Copy link
Copy Markdown
Owner

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

sclevine commented Jun 9, 2015

Copy link
Copy Markdown
Contributor Author

Yep, happy to help!

- Does not apply to goroutines that "defer GinkgoRecover()"
@sclevine

sclevine commented Jun 9, 2015

Copy link
Copy Markdown
Contributor Author

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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

onsi commented Jun 10, 2015

Copy link
Copy Markdown
Owner

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.

onsi added a commit that referenced this pull request Jun 10, 2015
`panic(nil)` in a test results in it immediately passing
@onsi onsi merged commit a2e78ca into onsi:master Jun 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants