When running with wallaby.js the mocha-jsdom setup breaks often about enzyme

[lelandrichardson]

@KnisterPeter since you are using a browser based test runner, you should be able to use enzyme without needing jsdom. As a result, can you try running your tests without using the describeWithDOM helper?

[KnisterPeter]

We are running our tests with wallabyjs in node. So this is not a browser based test. Sorry for missing that detail.

[lelandrichardson]

@KnisterPeter oops. No, that's my fault. I thought I knew what wallaby.js was, but apparently I didn't.

I'm not sure what the error is then. The error you're getting is an indication of mocha-jsdom attempting to create a window and document object, but finding them already on the global namespace and thus throwing. Does wallaby.js perhaps inject some browser-like APIs into the global namespace?

[KnisterPeter]

I don't think so. Maybe its 'watching' your code and then reevaluate or something like this.
Wouldn't it be possible for enzyme to add an option for 'skipWindowCheck' in the describeWithDOM method?

[ArtemGovorov]

@lelandrichardson wallaby.js supports both browser and node testing.

The issue is that mocha-jsdom deletes global.window in mocha after hook, and wallaby.js (as a continuous test runner) can't guarantee that the hook will be invoked.

For example, if you have a few async tests, and they are running, and you change your code at the same time, wallaby.js will force cancel the previous run, and the hook may not be executed (under some circumstances). Also some code changes may require wallaby to force cancel the run, for example introducing an infinite loop in your code or high level test structure errors. Because wallaby runs your tests as you type, the likelihood of such changes is much higher than when you run your tests occasionally with plain mocha.

mocha-jsdom exports a function that supports a few options (as @KnisterPeter mentioned skipWindowCheck is one of them that could help) and enzyme could support passing those options to it.

A cleaner solution only requiring a small addition to the wallaby config file would be to use wallaby.js teardown function to just delete the window object if it wasn't deleted by the after hook. The function is guaranteed to be called no matter what kind of changes wallaby.js had to deal with (unless the changes require to recycle node.js process, in which case you don't have to care about the window object anyway).

module.exports = function () {
  return {
    ...
    teardown: function(){
      delete global.window;
    }
  };
};

There's another solution which can make wallaby.js work just like other test runners (kill node.js process after tests are finished) with the workers.recycle option. Even though wallaby will still be faster then other runners (because it'll execute only affected tests, not all tests), you'll notice that tests are running a bit slower than without the option. I only recommend using the option when you really need that kind of a separate process isolation for each test run and can't really allow wallaby to reuse node processes.

[KnisterPeter]

Thanks @ArtemGovorov
I've created a pull request with the optional options for jsdom but I will give the teardown a try as well.