Skip to content
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

Recover in suite #695

Closed
YaroslavDev opened this issue Dec 4, 2018 · 3 comments
Closed

Recover in suite #695

YaroslavDev opened this issue Dec 4, 2018 · 3 comments

Comments

@YaroslavDev
Copy link

YaroslavDev commented Dec 4, 2018

IMHO, panic in tests is not a good idea. Not only because it's hard to understand what test panicked, but panic also crashes entire test run and some tests don't even start. I think it's a good idea to isolate each test run by putting a defer/recover so that you know exactly what test caused panic and give possibility for other tests to run.

Github PR implementing this feature: #696

@iaroslav-ciupin
Copy link

P.S.
If you want to test that some of your code panics as expected, you must explicitly put a recover in your test, catch actual panic and compare it with expected one.
IMHO,
Panic SHOULD NOT propagate outside scope of a test case, because in a context of testing panic is just another type of error that should be caught and checked.

@itzamna314
Copy link
Contributor

+1 to this. With test suites that have some environmental setup/teardown, a panic will exit tests before the teardown can happen. Then you've got resources you have to clean up manually.

Real-world example: I have a test suite that sets up a docker database container, then runs tests against it, and removes the container plus all volumes when everything is complete. If I have a panic in my code, I have to manually go through and clear out the container and its volumes.

@YaroslavDev
Copy link
Author

Merged

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

No branches or pull requests

3 participants