Circular dependencies in mongoose's modules can generate errors in unit tests

[bernardofd]

Hello;

After updating mongoose from 3.5.0 to 3.5.4, I've encountered errors in my test environment (jasmine-node + pow-mongodb-fixtures + sandboxed-module) giving the following message, always in the last it() statement:

Expecting a function in instanceof check, but got function Date() { [native code] }

The error was traced back to file lib/utils.js, line 455, which led me to Issue #1009. Trying to better document the error, I tried to implement a test that could isolate the problem, but this task was beyond my grasp. We've tried several trial and error solutions until two quick (and dirty) fixes presumably resolved the problem. I could either :

• add the following line into lib/types/index.js in mongoose's source code, removing array.js from the require cache before requiring it again:

delete require.cache[require.resolve("./array")];
exports.Array = require('./array');

• or run the unit test of my module outside the sandboxed-module environment. The sandboxed-module create a new context outside node where a module can be tested, to allow mocks and stubs for requires and dependencies.

Further investigating this behavior, we thought that this could be caused by circular requires, which could return a empty object instead of the actual module being loaded depending of the conditions (http://requirejs.org/docs/api.html#circular). As expected, when using a neat little tool called MaDGe, it detects several cycles in requires over the mongoose's source code, which can be visualized in the following graph (modules marked as red are part of a cycle of dependencies):

If I could guess which cycle is causing me those troubles, I would bet my money in the document -> schema -> namedscope -> query -> promise -> utils -> types/index -> types/array -> document cycle. It should be noted that this error is only encountered in the test environment, and not in production, since the require cache keeps the objects stored after the first require() call. But since the module is run in sandboxed mode, which clears the execution context for each test, the error was observed.

Hence, I think you guys should be aware of this potential flaw. I don't know if it is justified to rearrange the dependencies since this is a bug which I could not reproduce in an isolated test. But at least it should shed some light over the problem reported in #1009.

Thanks in advance.

[aheckmann]

Neat graph. Until the issue can be reproduced there is not much we can do. Care to share your test setup?

[bernardofd]

Hello. I'm sorry for the delay on this response, but we were quite busy in the last couple of weeks.

I don't know exactly what you would want for a 'test setup', but here it is as the best I can describe it: We use mongo as a DB solution, holding the documents for our web app focused on Distance Education (documents are defined through Schemas, e.g. Users, Images, Courses, etc...). For testing, we have a mock database on which we feed false data for testing purposes, directly into mongo through the pow-mongodb-fixtures lib. For each run, we load the fixture data into mongo and run the function through the jasmine-node framework, using sandboxed-module for context isolation.

While testing our functions, the last test in a test spec would always fail with the error message provided above. One would think that our code would be faulty, but if one would add an empty it() after the last behavior test, a test that does nothing, does not call any functions (expect change execution context (sanboxed-module), clear all the test DB data and reload all the fixtures(pow-mongodb-fixtures)), the test that previously failed would succeed, and this new empty test would fail with the same error message.

(Un)fortunately, I failed to reproduce this error with mongoose's latest version (3.5.6). I was using code from our app's server to reproduce the error (https://github.com/bernardofd/mongoose-error-prone), but after some minor tweaks, the error message vanished. So, I think you could close this issue, but I would suggest keeping an eye open for those circular dependencies, as they can potentially cause difficult to catch errors, as they did with me.

Thanks for the attention! :)