Closed lgtout closed 9 years ago
There's no DOM in node.js... You could probably fake something using jsdom, but that would be a little bit pointless - JS should be tested where it runs (i.e. if it's intended for use in the browser - use a browser, preferably a real one, although PhantomJS is better than nothing).
Ok. If that's the only choice. But then how would I test a CJS module that has a DOM dependency? Outside of tests, I use Browserify to make my CJS modules runnable in the browser.
I use browserify as well - I then load the final bundle via src
and run tests normally, in the browser.
Do you browserify the tests as well? If not, how do the unit tests get access to the modules they test? I find that I cannot "require" modules that are browserified from outside the browserify bundles.
I don't browserify tests - a global require()
itself is exposed and you do need to expose the module in the config - I use grunt-browserify
and its alias
property - not sure how is it done exactly with bare browserify - pretty sure there's docs :) It's not ideal, since it requires a bit of fiddling, but it's easy enough to set up and forget about it :) I'd love to see a better alternative, but it would involve peering into browserify bundle internals and modifying things and providing paths... it's probably worth looking into, but my current approach is good enough for me.
I am considering browserifying my tests for the sole purpose of using ES6 goodies, but it's kind of costly time wise and annoying when you're doing things with a watcher / auto-test.
@jaabio, as @dymonaz said, it doesn't make sense to use the buster-html-doc extension for node.js tests. But if you really need such a functionality for your node.js tests, for whatever reasons, feel free to write your own extension, which doesn't use document
but can be used for node.js tests.
I tried this, and was surprised it didn't work. Here's the test:
And the busterjs config:
At the command line: