Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Global state does not reset for C++ addons #2826

Closed
jingchan opened this issue Feb 7, 2017 · 11 comments
Closed

Global state does not reset for C++ addons #2826

jingchan opened this issue Feb 7, 2017 · 11 comments

Comments

@jingchan
Copy link

jingchan commented Feb 7, 2017

Do you want to request a feature or report a bug?
bug

What is the current behavior?
require()ing a native module across several tests does not reset that module's state

let mod = require('bindings')('myCppModule')
if(!mod.x) mod.x = 0;
mod.x++; // <-- this will continue to increment for each test that 
         //     requires the module or for subsequent runs of the test file.

To reproduce, see: https://github.com/jingchan/jest-issue-2826

What is the expected behavior?
The module's state should be the same every time to match the description from https://facebook.github.io/jest/:

Jest parallelizes test runs across workers to maximize performance. Console messages are buffered and printed together with test results. Sandboxed test files and automatic global state resets for every test so no two tests conflict with each other.

Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.
jest v18.1.0; node v7.5.0; npm v4.1.2; OSX Sierra & Windows 10

This is causing me issues when testing certain packages which wrap and replace the functions of the object returned from the require call. Any ideas for temporary workarounds would be welcome.

@thymikee
Copy link
Collaborator

thymikee commented Feb 7, 2017

Can you setup a brief repro of the issue?

@cpojer
Copy link
Member

cpojer commented Feb 7, 2017

I'm not sure if these can be unloaded.

@jingchan
Copy link
Author

jingchan commented Feb 7, 2017

@cpojer You may be right as this seems related to: nodejs/node#5016.

However, without unloading the binary, it might still be possible to revert the state of the JS object returned.

@jingchan
Copy link
Author

jingchan commented Feb 8, 2017

@cpojer
Copy link
Member

cpojer commented Feb 8, 2017

I don't think we are able to do so, as you pointed out in the node.js issue you linked to.

@thymikee
Copy link
Collaborator

thymikee commented Feb 8, 2017

Maybe it's worth to close it and reopen when the issue is resolved on Node side? I think this is something we would like to know works with Jest

@cpojer
Copy link
Member

cpojer commented Feb 8, 2017

Yeah I'm gonna close this out for now. If anybody has creative ideas on how to solve this, please let me know.

@cpojer cpojer closed this as completed Feb 8, 2017
@jingchan
Copy link
Author

jingchan commented Feb 8, 2017

Perhaps you can offer suggestions on what might be a workaround? This is causing me a lot of issues.

A suitable workaround would be a way to be able to require the module once and pass a reference to the tests without re-requiring it. I tried a custom test environment, but that was a no-go.

Right now this issue is completely preventing me from using Jest at all, so thoughts would be much appreciated.

@cpojer
Copy link
Member

cpojer commented Feb 8, 2017

Yeah, it should work with a custom test environment as long as you only create one instance.

Another solution could be to add a "__resetForTest" method to your native module that resets it in C++.

@liyikun
Copy link

liyikun commented Sep 11, 2019

I also encountered this problem and hope to have a solution. This problem makes me completely unable to use Jest at all.

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants