-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
try domains in a branch #513
Comments
(+1) Just wrote a small connect middleware with a domain per request (as in the explicit binding section of the api) and in the process realized that I can't unit-test it. Even if the domain catches the error, the "uncaughtException" callback will still be called, and
The example above, obviously, fails. |
+1 |
4 similar comments
+1 |
+1 |
+1 |
+1 |
+1 I've been trying to sort this one out as well. I've got a web framework that uses domains to catch request errors which I'd love to test. I've come up with a simple test case for how I would have expected Mocha to work here https://gist.github.com/3971280. I'm migrating from Vows to Mocha, and this this the only test I can't port. I understand the desire to keep Mocha applicable for browsers as well, so is there a monkey-patch solution anyone has come up with for now? |
Fwiw @dscape's specify was designed to work with domains. Never had the chance to use it myself though. |
If you look at the domain module's In the meantime, it's a bit confusing as to what is happening if you're not familiar with how domains are implemented, b/c you're successfully catching the error, but the test still fails. |
fyi domains use |
Yup. I guess my point about it seeming confusing was in regards to domains not actually catching any errors, which has nothing to do with mocha. It belongs on the node issues, but |
Works in |
@CrabBot cool solution, but I tired it out, and it doesn't look like it passes my test use case https://gist.github.com/3971280. In fact, it looks like the code isn't entering |
After digging in the code of both mocha and node, I implemented a simple workaround: Is it the way to go? May it be possible to automate it in a function call like |
A bit of a hack, but that works for me as well! |
FWIW, going forward, domains will not use |
@evantahler If I recall correctly, there are two https://github.com/visionmedia/mocha/blob/master/lib/runner.js#L456-L473 Again, if I recall correctly, adding it to the former is what worked for me. Did it not work for you? |
@CrabBot : @mcollina 's solution worked for me. You are correct that at the time of test invocation it does look like there are 2 functions bound to the global uncaughtException, and removing the last (newest) one was the trick. If you are curious, here is the (now working!!!) test suite for actionHero which tests the notion of rendering a |
Despite the fix in the node codebase from issue #4375 there still seems to be a problem testing while using node.js domains. It seems that mocha wraps the test function in try catch blocks which means that any synchronous errors are caught by the try catch block and aren't ever caught by the domain. I have detailed a test case in my answer to the following question. While there is a workaround: Wrapping all tests in process.nextTick(function(){ ... }); It seem that a small change to the mocha codebase would make this unnecessary. In my tests removal of the try catch blocks in runnable.js and runner.js alleviates the need for the workaround. If there is an unhandled synchronous error it is still caught by the uncaughtException handler by mocha and reported similarly to the case where the try catch block was in place. I would make a pull request, but I am unsure of the impact to other (non nodejs) environments. There are a number of possible approaches:
Others? What's the preferred way to detect the context we are running in for mocha and branch accordingly. I am happy to make the changes if given guidelines. |
domains are deprecated :D |
Whoa! That's news to me. Google and http://blog.nodejs.org/ doesn't turn anything up... have a link? |
it was a conference. well he said, "i want to deprecate domains", so that's basically deprecating it |
I confirm. |
@jonathanong said:
OK, this is exceptionally lame.
|
this will fuck over client-side support nicely but yeah
The text was updated successfully, but these errors were encountered: