-
-
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
Make sure mocha -h
consistently shows help
#2746
Conversation
The problem is when
|
This looks good to me; @mochajs/core do we want to add a test for this behavior? |
There should be, imo. |
@boneskull, I tried. I'm not sure if I did it the way you'd prefer, but this is definitely a test that fails without this commit and passes with it. |
I'm not sure why the test failed in AppVeyor. Does anyone have advice? (It works on my local computer.) |
I can't see the actual failure in the AppVeyor test either... Travis is only failing the new test on the oldest version of Node. Unfortunately, its not too clear why it's failing (except that it's the assertion that failed) since the assertion library used in that test file is boolean-based. It may be necessary to switch it to one of the other assertion libraries used in Mocha's tests that supports a |
@ScottFreeCode can you do that? I don't really know how to. |
test/integration/options.spec.js
Outdated
|
||
describe('--help', function () { | ||
it('works despite the presence of mocha.opts', function (done) { | ||
var output = ''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This initialization is redundant since an implicit casting is being done on line 195.
test/integration/options.spec.js
Outdated
var mochaLoc = path.resolve(__dirname, '../../bin/mocha'); | ||
output = '' + childProcess.execSync(mochaLoc + ' -h', {cwd: path.resolve(__dirname, 'test-env')}); | ||
} catch (e) {} | ||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sequence of try...catch
blocks here are for setup and teardown, and should be shifted to before
and after
blocks, outside this it
block.
test/integration/options.spec.js
Outdated
fs.rmdirSync(path.resolve(__dirname, 'test-env')); | ||
} catch (e) {} | ||
assert(output.indexOf('Usage:') >= 0); | ||
done(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The entire test is synchronous, and as such, the done
callback is not needed here.
@Zarel What @ScottFreeCode was referring to was tweaking: assert(output.indexOf('Usage:') >= 0) to something like: expect(output).to.contain('Usage:'); Here, Additionally, you could also log the actual output so that we can see what exactly is coming up in the CI builds. |
Sorry about the late followup...
This should happen automatically if a more detailed assertion is used such as that Aside from that, @Zarel, @kunagpal's suggestions all look good to me at a glance; feel free to try applying any/all of them. This might also end up having to be... merged a bit with other updates that have been made to |
Actually, looked at the conflict and -- seriously -- GitHub was confused because two entirely separate sets of tests were added to the same file? It couldn't figure out to just keep both additions? Eh, whatever; I went ahead and resolved that. |
It looks like the problem for AppVeyor is:
Is Mocha built/run a different way in Windows? |
The Travis failure on Node 0.10 turns out to be due to child_process.execSync not existing till Node 0.11... The Windows error... sounds to me as though it is trying to run the Mocha script as though it were an executable? I'm sure we have some helpers in Mocha's testsuite somewhere that will run a separate CLI instance of Mocha properly on both OSes and all versions of Node; let me see if I can find them and get back to you. |
So, I found an integration test helper and used it to do this (added a commit to the branch), although... it runs Mocha from the current working directory, so if we wanted to be absolutely sure that the opts file contains "foo" (rather than presuming that a mocha.opts file at all would trigger the issue we're fixing), then we'd have to tweak the helper to make it possible to override the current working directory. Hmm. |
Unfortunately, only certain things in |
Still, though, this level of struggling seems excessive to leave a bug unfixed. (I don't have mocha options memorized and it's mildly annoying to have to |
It seems weird to leave a bug unfixed because your test framework doesn't support testing the fix? |
@ScottFreeCode does this need anything or can it be merged? |
Previously, having options in `test/mocha.opts` would add those to `process.argv` to be passed to `program.parse`, which would make it stop showing help. Fixes mochajs#2745
…rrent working directory, so make test/mocha.opts be available if necessary without overwriting existing one if any
Changes Unknown when pulling 8621eb0 on Zarel:patch-2 into ** on mochajs:master**. |
Rebased to fix the merge conflict. |
For the record, I have trouble testing this; I get a different error every time I run
|
I think the initial test was correct but didn't work on Windows, then my attempt to use the existing cross-platform helpers (because Node really makes portable spawning/forking difficult) worked on Windows but didn't actually prove that the fix works (unlike the original test). I verified this by pulling down the code and trying the test with and without the fix in the source. So... had to think about it a while, but I should have something that can test this correctly cross-platform and will be pushing it up shortly. If that passes CI we should go ahead and merge this already -- it's waited longer than it should have. |
Changes Unknown when pulling da32727 on Zarel:patch-2 into ** on mochajs:master**. |
All CI passed except linting (oops, should have done that before pushing); pushed a fix for the linting error, going to merge. |
* Make sure `mocha -h` consistently shows help Previously, having options in `test/mocha.opts` would add those to `process.argv` to be passed to `program.parse`, which would make it stop showing help. Fixes mochajs#2745
Previously, having options in
test/mocha.opts
would add those toprocess.argv
to be passed toprogram.parse
, which would make it stop showing help.Fixes #2745