Command not unit test friendly

[phdunham]

I a lot of unit tests for my code to test parsing the command line. Commander instantiates on the require('command') statement and is cached. My unit tests do not have a way to reset commander back to its initial state. Many of my unit tests fail because values from the previous unit tests inside of commander carry over.

can we get a way to create a new Commander() each time for unit testing. Or at least a function like commander.reset() to flush the previous state of commander between unit tests?
Thanks

[tandrewnichols]

You can use proxyquire to control it, or . . . if you don't like stubs (depends on your school of thought for tdd), use clear-require to reset the state of the module and then require it again.

[lukeasrodgers]

@phdunham you could try the approach in my PR #499, or follow the approach taken by commander.js itself, i.e. each test in a separate file.

[skratchdot]

It would be nice to have the library stop using globals, and allow things like "log" and "error" to be passed as options. Also consistent usage of console.log vs process.stdout.write (always using console.log seems like the way to go).

I've had a pretty miserable time trying to unit test my cli w/ code coverage. I ended up needing to use spawn() to write my tests (which works okay), but I haven't gotten coverage w/ istanbul working yet. When I tried using sinon to override things like process.exit, and process.stdout.write, I entered the rabbit hole.

Started working on a PR here to allow all globals to be passed as params, but that didn't seem like it would actually help in the end. Hopefully someone here can post some links to successful cli unit testing with code coverage! I know I'd be interested in other examples (my approach isn't the best- and other examples I've tried never work in my codebase)...

[nene]

Turns out that the solution already exists. The Command class can easily be imported and instantiated:

import {Command} from "commander";

const commander = new Command();
// now use the local instance as you would use the global one...

It simply doesn't seem to be documented anywhere besides the code itself.

I ran into this problem once again when I was upgrading to Mocha 3.x. Suddenly all my tests against commander started to fail as Mocha was also using the global commander instance and the command line options my library was using got mixed together with command line options of Mocha. Rewriting my CLI to instantiate separate Command class solved the whole problem easily.

[segfaultmedaddy]

You can use new commander.Command() to instantiate a new Commander instance. Close for now.

[akataz]

@vanesyan thanks for that i've been puzzled for a while! Worked like a charm.

[ChristofferSkog21st]

Are there any unit testing examples? Haven't been able to find any.

[shadowspawn]

There are the unit tests for Commander itself. Most of them predate the "new commander.Command" style but these two got updated recently.

• https://github.com/tj/commander.js/blob/master/test/test.options.bool.no.js
• https://github.com/tj/commander.js/blob/master/test/test.options.bool.js

[ChristofferSkog21st]

@shadowspawn Yeah saw those, thanks. I can't find any way of testing commands that have prompts in them though, is that even possible?

[shadowspawn]

What prompts? I have seen Commander did once support prompts (e.g. #163) but not since I started using it, so that might be another library.