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

(re-)enable after each hooks to fail tests. #1944

Closed
wants to merge 1 commit into from

Conversation

jjoos
Copy link

@jjoos jjoos commented Oct 23, 2015

In version 1.2.1, support was added to fail test in the after each hook:

While migrating from teaspoon-mocha to karma-mocha, we discovered that
in the current mocha version this isn't supported anymore. That behaviour has been changed in: ebc6aee without any documentation change.

If this was a conscious decision adding some documentation about dropping this functionality would then be nice. The old behaviour is documented in: https://github.com/mochajs/mocha/wiki/Conditionally-failing-tests-in-afterEach()-hooks .

@@ -16,7 +16,7 @@ describe('multiple calls to done()', function() {

it('results in failures', function() {
assert.equal(res.stats.pending, 0);
assert.equal(res.stats.passes, 1);
assert.equal(res.stats.passes, 0);
Copy link
Author

Choose a reason for hiding this comment

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

As far as I can tell this is a bug that has been fixed by my changes, this is the content of the test fixture:

describe('Multiple Done calls', function(){
  it('should report an error if done was called more than once', function(done){
    done();
    done();
  })

  it('should report an error if an exception happened async after done was called', function (done) {
    done();
    setTimeout(done, 50);
  })

  it('should report an error if an exception happened after done was called', function(done){
    done();
    throw new Error("thrown error");
  })
})

Copy link
Contributor

Choose a reason for hiding this comment

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

Are you sure that code corresponds to the right test? Running that with mocha --reporter json on master yields:

  "stats": {
    "suites": 1,
    "tests": 3,
    "passes": 3,
    "pending": 0,
    "failures": 2,

Copy link
Contributor

Choose a reason for hiding this comment

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

Nvm, the fixture highlighted above is the wrong one. It's actually: https://github.com/jjoos/mocha/blob/master/test/integration/fixtures/multiple.done.js Which makes sense then :) Since its contents are:

it('should fail in a test-case', function(done) {
  process.nextTick(function(){
    done();
    done();
  });
});

In that case, your code is an improvement! I'd be curious if you fixed the issue here as well: https://github.com/jjoos/mocha/blob/master/test/integration/fixtures/multiple.done.js#L4-L11

Copy link
Author

Choose a reason for hiding this comment

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

Ah sorry for quoting the wrong fixture.

I actually looked at the commented out section of that fixture, but didn't know what the the correct behaviour is.

If I uncomment that fixture, the change to the test to make it pass looks like this:

     it('results in failures', function() {
       assert.equal(res.stats.pending, 0);
-      assert.equal(res.stats.passes, 0);
-      assert.equal(res.stats.failures, 1);
-      assert.equal(res.code, 1);
+      assert.equal(res.stats.passes, 1);
+      assert.equal(res.stats.failures, 2);
+      assert.equal(res.code, 2);
     });

Which seems strange since the beforeEach error should cancel the execution of the test, but doesn't do that (I confirmed that the test is executed) But this could be an acceptable limitation of the async beforeEach implementation. If you clarify if this is acceptable I can uncomment it in my PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

Nvm, I'd leave that be then :)

@danielstjules
Copy link
Contributor

Related: #1635

@danielstjules
Copy link
Contributor

Mind rebasing on top of master? :)

@danielstjules
Copy link
Contributor

Heh, anytime we touch the runner code, it's a lot to QA 😅

In version 1.2.1, support was added to fail test in the after each hook:
>* Added `this.test.error(err)` support to after each hooks. Closes mochajs#287

While migrating from teaspoon-mocha to karma-mocha, we discovered that
in the current mocha version this isn't supported anymore. That
behaviour has been changed in: ebc6aee
without any documentation change.

If this was a conscious decision adding some documentation about
dropping this functionality would then be nice. The old behaviour is
documented in:
https://github.com/mochajs/mocha/wiki/Conditionally-failing-tests-in-afterEach()-hooks
.
@jjoos
Copy link
Author

jjoos commented Mar 23, 2016

@danielstjules Ah missed #1635, this pr will fix that issue. Just rebased this commit on master.

@jjoos
Copy link
Author

jjoos commented Mar 23, 2016

Ah missed #1635, this pr will fix that issue.

I spoke too soon, it won't fix that issue, but it will give them a reasonable workaround.

Fixing #1635 would mean a far bigger overhaul to consolidate the way the assertion errors are caught. And then apply that to a subset of the hooks.

@danielstjules
Copy link
Contributor

spoke too soon, it won't fix that issue, but it will give them a reasonable workaround.

Exactly what I'm thinking :)

@glenjamin
Copy link
Contributor

I think if this gets merged it'd be reasonable to close #1635 as the main reason I requested it would be to do exactly what this PR enables.

@j-funk
Copy link

j-funk commented May 31, 2016

Was very excited when I found the wiki article - alas it is not working - can we get this soon?

https://github.com/mochajs/mocha/wiki/Conditionally-failing-tests-in-afterEach()-hooks

@hollomancer hollomancer added the status: needs review a maintainer should (re-)review this pull request label Aug 28, 2016
@j-funk
Copy link

j-funk commented Oct 5, 2016

@jjoos any chance you're up for fixing the merge conflicts? This would be a huge help if/when it gets merged!

@glenjamin
Copy link
Contributor

I'm happy to adopt this if it's likely to be merged afterwards.

There was a time when it was mergeable but wasn't integrated - so I'm not sure whether there was some other reason it wasn't accepted.

@j-funk
Copy link

j-funk commented Oct 19, 2016

@danielstjules sry to push on this so much, are you a potential gatekeeper for this?

@hrimhari
Copy link

Any news about this?

@arikon
Copy link

arikon commented Jul 20, 2017

Anybody?

@Rush
Copy link

Rush commented Aug 17, 2017

Any updates? Does a workaround exist?

@Rush
Copy link

Rush commented Aug 19, 2017

FYI, pasted a workaround here #1635 (comment)

@boneskull
Copy link
Contributor

can't use this unless the CLA is signed; please reopen if interested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs review a maintainer should (re-)review this pull request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants