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

fix improper warnings for invalid reporters #4275

Merged
merged 3 commits into from May 14, 2020

Conversation

boneskull
Copy link
Member

also: reorganize, add, and refactor a bunch of problematic unit tests for lib/mocha.js. better isolation except where we can't really do that (calling require)

there's still missing tests in here, but this is an improvement.

@craigtaub this touches some stuff regarding warnings for invalid reporters. it looks like the conditionals were backwards?

@boneskull boneskull added type: bug a defect, confirmed by a maintainer type: chore generally involving deps, tooling, configuration, etc. semver-patch implementation requires increase of "patch" version number; "bug fixes" labels May 8, 2020
@boneskull boneskull requested a review from craigtaub May 8, 2020 21:27
@boneskull boneskull self-assigned this May 8, 2020
@boneskull boneskull force-pushed the boneskull/mocha-unit-tests branch from 65b5a7d to 1ba7cc6 Compare May 8, 2020 21:30
@boneskull
Copy link
Member Author

I should note that I started out adding more coverage and refactoring, but I found a bug while I was doing that...

@craigtaub
Copy link
Contributor

craigtaub commented May 9, 2020

Odd the logic been broken for so long for such an important check. Would have been good to see an issue or details in the description to help replicate locally.

Would this logic apply all the time or just programmatic use of mocha only? (cli catches bad reporters when I try locally)

lib/mocha.js Show resolved Hide resolved
@boneskull
Copy link
Member Author

can't use require.resolve in unit tests because browser. will need to move some of these into test/node-unit/mocha.spec.js

@boneskull
Copy link
Member Author

OK, we can't use rewiremock in test/unit/*.spec.js because it's apparently incompatible with browserify as written. so I've ripped it out of there, and moved some tests for Mocha#reporter() into test/node-unit/mocha.spec.js where we can safely test reporter resolution.

Ref: theKashey/rewiremock#113

cc @Munter -- how's the transpilation coming? 😄

@coveralls
Copy link

coveralls commented May 11, 2020

Coverage Status

Coverage increased (+0.08%) to 93.228% when pulling 0bd7e14 on boneskull/mocha-unit-tests into 81e203c on master.

@boneskull
Copy link
Member Author

tests broke because you can't use Object.assign() in IE11 (I forgot), but I noticed we also didn't have a lint rule preventing it, so I added one.

@boneskull
Copy link
Member Author

@nicojs I had heavily refactored test/unit/mocha.spec.js, where most of your new tests live--so they, too, are assimilated in this PR. May want to take a look.

@nicojs
Copy link
Contributor

nicojs commented May 12, 2020

@boneskull You're not kidding, file looks like a Christmas tree in my browser 🎄. Will checkout this branch locally to take a better look. Will have to wait till tomorrow.

@boneskull
Copy link
Member Author

your changes highlight that Mocha.prototype.run has a very strange API.

It accepts an optional callback, and that callback is called with a single parameter, failures, a number. This doesn't conform to a typical convention. If it did use an error-first style, that convention expects the function to not throw, and rather call the callback w/ an Error instance.

It would likely be highly disruptive to break this, unfortunately. Off the top of my head, two ways we could improve the situation:

  1. The way forward may instead be to create a new runAsync (or whatever) in the future and return a Promise. If the Runner instance is needed (the current return value) then this would not be appropriate.
  2. In Mocha.prototype.run, inspect the callback. If it exists and has an arity greater than 1, use an error-first style; otherwise use the current behavior.

Consumers of Mocha.prototype.run don't currently expect it to throw (for any reason), and the current situation may be awkward to work with.

Copy link
Contributor

@nicojs nicojs left a comment

Choose a reason for hiding this comment

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

Looks good to me! Some minor suggestions.

test/node-unit/mocha.spec.js Outdated Show resolved Hide resolved
});

describe('when the reporter throws upon load', function() {
it('should throw "invalid reporter" exception', function() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Love the fact that this is split out from the should warn ... test 😍. Also for the mocha unit tests.

also: reorganize, add, and refactor a bunch of problematic unit tests for `lib/mocha.js`.  better isolation except where we can't really do that (calling `require`)

there's still missing tests in here, but this is an improvement.
- better isolation
- a use of `process.cwd()` in `lib/runner.js` was left in place to avoid conflicts, because another PR will remove it
@boneskull boneskull merged commit 1a4646d into master May 14, 2020
@boneskull boneskull deleted the boneskull/mocha-unit-tests branch May 14, 2020 21:49
@craigtaub craigtaub added this to the next milestone May 21, 2020
craigtaub pushed a commit that referenced this pull request May 21, 2020
* fix improper warnings for invalid reporters

    also: reorganize, add, and refactor a bunch of problematic unit tests for `lib/mocha.js`.  better isolation except where we can't really do that (calling `require`)

    there's still missing tests in here, but this is an improvement.

* restrict use of Object.assign in ESLint config
* add wrapper around process.cwd()
    - better isolation
    - a use of `process.cwd()` in `lib/runner.js` was left in place to avoid conflicts, because another PR will remove it
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver-patch implementation requires increase of "patch" version number; "bug fixes" type: bug a defect, confirmed by a maintainer type: chore generally involving deps, tooling, configuration, etc.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants