-
Notifications
You must be signed in to change notification settings - Fork 46
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
Assertions within async callbacks timeout instead of failing #78
Comments
Perhaps this is a similar issue? I have tested and it does seem that wrapping in it 'will fail immediately v2', (done) ->
Meteor.setTimeout ->
setTimeout ->
assert.equal 1, 2
done()
, 0
, 1 Although unfortunately this seriously messes with the output, even getting rid of the time taken. will fail immediately - 45 ms output from try/catch method above will fail immediately v2 - ms is missing the time |
I'm facing the exact same problem. The |
Could this please be marked somewhere in the README? |
I tried using the try/catch in my Meteor app to catch the asynchronous assertions and it prevented velocity from working. I had to remove the try catch and velocity would then reload and run the tests again. The solution that worked for me was wrapping the chai.assert statement in a setTimeout. Does this solution work for others using Meteor mocha? Any downsides to this hack/fix? |
So it seems like any assertions that are made within meteor-specifc callbacks (e.g.
Meteor.setTimeout
orMeteor.call
) will not fail the test immediately, and will wait for mocha to timeout.@dangilkerson has a solution in #70. The solution is illustrated in the last example below, but it would be nice to not have to do this.
Seems like failed assertions should behave in the same way as if the assertion passes, and cause the test to fail immediately. It also means that unless you use the try/catch solution, the test failure is reported as 'timeout' instead of the actual assertion.
Here's a few examples to demonstrate:
The text was updated successfully, but these errors were encountered: