Problems with Mocha / Jsdom / React testing

[Munter]

This is a crosspost with facebook/react#4025 because I'm not sure if the problem is with Mocha or React

I'm not entirely sure if what I'm having here is a problem with Mocha or React, but I really need some help figuring out why my tests are failing with what looks like leaks across siloed documents.

My test setup is using Mocha, where each individual test spins up a document with jsdom before loading React. I then proceed to run the test of the individual component in each of these separate documents.

My tests run fine if I only run a single file at a time, but when I run all tests I get errors like DOMException: Wrong document (from jsdom) and Error: Invariant Violation: findComponentRoot(..., .1): Unable to find element... (from React).

I've created a repository with a minimal setup and a more detailed description here: https://github.com/Munter/MochaJsdomReact

Can anyone help me figure out what the problem is, and how to avoid it, or maybe even fix it?

[jbnicolai]

I fear I'm out of my depth here.. suspecting it's an issue with jsdom though.

[Munter]

It looks like React is using memoization of a DOM node when it is first instantiated, which is also the reason for the need to have created a jsdom document and leaking a global document and window variable before loading React.

It seems that the leak across tests is caused by the require cache being shared across test instances, resulting in a React instance in test-2 which uses a dom node from a different document to create it's document elements. This is what causes the Wrong document error from jsdom, which is just jsdom following the spec to the letter.

Would there be a way to configure mocha not to use requires cache between tests, or even have it run each test in separated processes?

[dmatteo]

According to this quite old issue (#536), the only way to make mocha use a new process/context for each test suite is to run test files individually... Which is of course a non solution.

Thus the need of a more canonical way of doing it (disable caching entirely could also be an option, if possible)

[akhaku]

Ran into a similar problem a while ago, my solution was to "undefine" requirejs modules after every test. I wrapped requirejs.require in a function that pushes the name of the module it's requiring to an array. Added a function called reset() that goes through and calls undef on each of the modules in the array. I call reset() after every test suite.

[jbnicolai]

@akhaku perhaps you'd be interested in https://github.com/sindresorhus/require-uncached

[jbnicolai]

I'm afraid I'm going to have to close the issue, as it's not a problem with mocha itself but the specific usage of it in this case which leaks context between tests.

Would there be a way to configure mocha not to use requires cache between tests, or even have it run each test in separated processes?

The first would be possible, using something like require-uncached, but might not be desirable. The latter would be possible using something like webworkers/multiprocesses, but since mocha supports both browser-based usage as CLI through node/iojs I fear this would be a lot of work to properly implement.

[dmatteo]

I see, that's too bad.
I thought mocha's tests were entirely isolated from one another, but this changes it.

@akhaku I'm doing something similar in jsdomify.destroy() method now, clearing require.cache entries that match our pattern, but it adds an extra 1.5s in our 7s run, which is unfortunate but I guess is the only solution right now.

Maybe something more clever will come to mind one day ;)

Thanks guys

[Munter]

@jbnicolai Thanks for taking the time to look into this

[jbnicolai]

I thought mocha's tests were entirely isolated from one another, but this changes it.

It's really an issue with nodejs/require, but I agree that it's an issue and that it'd be nice if mocha would work around it somehow. Thing is, un-caching everthing is really, really, slow.. :(

For reference: this issue is a duplicate/has the same underlying cause as #736