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

BDD-style interface still active when other interface selected in CLI #2207

Closed
ScottFreeCode opened this issue Apr 14, 2016 · 4 comments
Closed
Labels
type: bug a defect, confirmed by a maintainer

Comments

@ScottFreeCode
Copy link
Contributor

When Mocha is run from the CLI and another interface is selected, BDD-style tests are still run. For instance, create the following two test files and then run mocha -u exports to see two tests run instead of only one.

test/bdd.js

it("should run only if the other does not", function(){})

test/exports.js

exports["should only run if the other does not"] = function(){}
@dasilvacontin
Copy link
Contributor

instead of only one

Instead of a ReferenceError: it is not defined.

Thanks for pointing this out. It's not a priority though.

@dasilvacontin dasilvacontin added the type: bug a defect, confirmed by a maintainer label Apr 14, 2016
@jmm
Copy link

jmm commented Apr 14, 2016

I brought this up on gitter a couple days ago, but there was no response. This is really bad behavior. Especially since the documentation does a poor job of explaining the hooks. The main explanation of it portrays it that the hooks will always be the ones from the bdd interface, which combined with this bug makes for a bad situation.

@ScottFreeCode
Copy link
Contributor Author

Thanks to @codermarcos at #2994, I've also discovered that if --watch is used and this problem occurs the BDD tests on the subsequent watch-triggered runs will niether throw with a reference error nor actually register their tests -- you can get results like "1 passed, 0 pending, 0 failed" the first time followed by results like "0 passed, 0 pending, 0 failed" when the watch is triggerred.

@juergba
Copy link
Contributor

juergba commented May 6, 2019

Can be closed, was fixed with release v6 and the implementation of yargs.

@juergba juergba closed this as completed May 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug a defect, confirmed by a maintainer
Projects
None yet
Development

No branches or pull requests

4 participants