Jest: Node environment doesn't allow testing of libraries like Nightmare

[migueloller]

I'm trying to write tests for a small scraper I built with Nightmare. Because it uses Electron it's not possible to test it with Jest. I think the issue has to do with the variables that are exposed globally in the environment. The tests do work with Mocha but it would be awesome if I could just simply run the tests in my local environment (as opposed to the Jest sandbox).

[cpojer]

This isn't really actionable for us. Can you provide a repository on github that we can install and test to see what is missing?

[migueloller]

Let me distill the code to get a repro that is as simple as possible. I'll post it in a bit.

[migueloller]

Here is the repo: https://github.com/migueloller/jest-nightmare-bug

First, npm install.
node . works.
npm test doesn't work.

At least this time there is an error message but in my original code the promise just hangs.

[migueloller]

It's worth mentioning that the error occurs in the call to nightmare.end(). Check out this branch: https://github.com/migueloller/jest-nightmare-bug/tree/hangs. Here the test passes but the process hangs because Electron is still running in the background.

[cpojer]

Would you mind trying:

• Use jest@test (the latest development version)
• As a workaround: use the jest-environment-jsdom value for testEnvironment.

[migueloller]

The repo is already using jest@test. When I set "testEnvironment": "jsdom" in my package.json and run the tests I get TypeError: TestEnvironment is not a constructor.

[cpojer]

Try jest-environment-jsdom – we haven't published the fix for just using jsdom to @test yet.

[migueloller]

That doesn't fix the issue. I made a new branch for it.

[migueloller]

Hey @cpojer do you want me to make a branch that runs the test using Mocha for comparison or is that unnecessary?

[cpojer]

Sorry about the trouble. If you stick "persistModuleRegistryBetweenSpecs": true into your config and call example().end().then(…) in your test it will work.

You can also return the promise from it without using done at all.

We'll make the module registry persistent in the next major version of Jest, as people have trouble with it.

[migueloller]

No worries @cpojer! I'm extremely grateful of all the great work that's been put into Jest. I think it's the best testing tool out there for JS.

I was trying to find a configuration option like this on the docs but it doesn't seem to be documented. Is this something that should be added?

Also, would it be too much to ask you to explain why this issue was happening? I'm curious. 😅

Thanks!

[cpojer]

We'll make this the default and have an opt-out to the current behavior. It's currently internal.

Jest resets the module registry before every test for isolation but people don't enjoy using this feature in open source and prefer to use imports or top level requires.

Example:

const React = require('React');
jest.resetModuleRegistry() // implicitly happens in beforeEach right now
const React2 = require('React');
React === React2 // false!

but this requires people to write their requires inside of it calls instead of at the top level and they won't be able to use imports. People do that though, so we'll make it the default.

It just happens that the stream library has a "lazy require", ie it requires something inside of a function call. If you have a reference of a module from the first module registry and you call something on it and that requires something every time, when the module registry gets reset, it loses it's reference and re-requires it. That way a module, during its lifetime, might use different instances of different modules and that gets messy and it is too magical, so we'll kill it.

[migueloller]

So after trying to write my tests again today I came across another bug with using Nightmare. This time I took the time to figure out exactly what it was.

It looks like Jest mocks the global setTimeout which Nightmare uses internally to wait for elements to appear in the DOM or simply to wait a set time. I've updated the repo I linked to before to include this new bug.

Is there a way to disable the mocking of timers in Jest?

[cpojer]

jest.useRealTimers()

We will make this a default soon as well.

On Sat, Aug 20, 2016 at 1:28 AM +0200, "Miguel Oller" <[email protected][e-mail]> wrote:

So after trying to write my tests again today I came across another bug with using Nightmare. This time I took the time to figure out exactly what it was.

It looks like Jest mocks the global setTimeout which Nightmare uses internally to wait for elements to appear in the DOM or simply to wait a set time. I've updated the repo I linked to before to include this new bug.

Is there a way to disable the mocking of timers in Jest?

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/facebook/jest/issues/1448#issuecomment-241159472, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAA0KIMK29IKQk8yR9JUPj53cUcCVWW9ks5qhjv9gaJpZM4Jm5Hf.

[migueloller]

I found another issue (hopefully I'm helping and not just being annoying).

Everything is working fine but if the --coverage flag is passed then it hangs again. I'm also having a different issue with coverage but in a more complex scenario. I'm hoping that fixing this issue in this small repo will be reflected on the bigger example.

I updated the repo to reflect this.

EDIT: The error message looks like __cov_Cpf7usAEqmWeAH4hZkuvAPdGWAw is not defined.

[cpojer]

@dmitriiabramov would you mind cloning the master branch in this repo and running jest --coverage and investigating a bit?

[atkinchris]

I'm also encountering issues with Nightmare when paired with Jest, especially with errors about stream. For anyone using this after Jest 15, @cpojer's persistModuleRegistryBetweenSpecs is now configured by resetModules - and setting it to false fixed my issue.