Better error handling when server fails to start during testing (see issue #7) #8
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
May 19, 2015 21:16
|
Thanks. The crash is a rough one. I suppose you could work around it by spawning the smoke tests in a new process, similar to the way the PhantomJS tests worked, but I'm not sure the trouble would be worth it. |
jamesshore
changed the title
|
This is a good change, but I've decided not to integrate it at this time. See issue #7 for discussion. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[See issue #7]
This fixes the bad error message when the server port is already occupied, but it doesn't address the real problem with firefox and selenium.
The firefox/selenium-bug seems to be hard to get by. Selenium crashes with a SIGSEGV and gives mocha no chance to clean up. I can't see a simple way to try/catch that in nodejs either. https://github.com/ddopson/node-segfault-handler created a module that writes a stack-trace when nodejs dies, but that module doesn't make any attempt to stop the actual core-dump.