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

require.requireActual not returning the actual mock #1273

Closed
calclavia opened this issue Jul 9, 2016 · 10 comments
Closed

require.requireActual not returning the actual mock #1273

calclavia opened this issue Jul 9, 2016 · 10 comments

Comments

@calclavia
Copy link

I create a simple test with Jest's default automatic mocking. I'm trying to test one of my app's modules, so I need to make sure the module I am testing is not mocked. However, using jest.unmock('../moduleName') did not seem to work.

I also tried using require.requireActual('../moduleName'), which also did not work.
https://facebook.github.io/jest/docs/api.html#require-requireactual-modulename

Context: Using latest TypeScript and React Native. All source and test files are written in TypeScript. Using a tsprocessor for Jest.

Printing out the module that I intend to test seems to indicate that it is mocked, even when I explicitly told it not to mock this module:

{ MyClass: 
   { [Function: MyClass]
     _isMockFunction: true,
     _getMockImplementation: 
      { [Function]
        _isMockFunction: true,
        _getMockImplementation: [Function],
        mock: [Object],
        mockClear: [Function],
        mockReturnValueOnce: [Function],
        mockReturnValue: [Function],
        mockImplementationOnce: [Function],
        mockImpl: [Function],
        mockImplementation: [Function],
        mockReturnThis: [Function] },
     mock: { calls: [], instances: [] },
     mockClear: [Function],
     mockReturnValueOnce: [Function],
     mockReturnValue: [Function],
     mockImplementationOnce: [Function],
     mockImpl: [Function],
     mockImplementation: [Function],
     mockReturnThis: [Function] } }
@vvo
Copy link
Contributor

vvo commented Jul 9, 2016

jest.unmock('../moduleName') should work as expected if the path to the module is the same as the import done in the code you are testing

@calclavia
Copy link
Author

@vvo Here's a more specific example that did not work:

My test file (I'm trying to test TwitterProtocol module):

jest.unmock('../twitterProtocol')
import { TwitterProtocol } from '../twitterProtocol'

I believe the above code is correct?

@vvo
Copy link
Contributor

vvo commented Jul 9, 2016

I believe the above code is correct?

Yes this should work, can you create a simple repository test folder on github so we can investigate?

@cpojer
Copy link
Member

cpojer commented Jul 11, 2016

Thanks for opening an issue. imports in TypeScript work similarly to ES2015 – they are hoisted above all other statements. When using babel-jest, we actually hoist unmock calls above imports. If you are using TypeScript, we don't have this custom transform available unfortunately.

Here are a few ways to work around this issue:

  • Disable automocking completely ("automock": false) in the config.
  • Instead of import, use require inside of your test files.
  • Use babel-jest in your typescript preprocessor after processing your typescript code into JS. (basically: return babelJest.process(tsOutput, filename); ).
  • Create a separate module that unmocks specific modules (not recommended).

Of course, the right way to fix this would be a plugin for typescript that hoists jest.unmock calls.

@cpojer cpojer closed this as completed Jul 11, 2016
@calclavia
Copy link
Author

@cpojer Would such a plugin for TypeScript be difficult to make? If it's not too difficult, I can give it a shot.

@cpojer
Copy link
Member

cpojer commented Jul 12, 2016

I don't know, does TypeScript have a plugin system like babel does or is the compiler still completely closed?

@aaronabramov
Copy link
Contributor

@cpojer would it make sense to run babel-preset-jest transformation on top of anything that is not babel-jest?
this would solve the coverage problem too

@aaronabramov
Copy link
Contributor

so basically.. if you're using babel-jest you get babel-plugin-jest-hoist and babel-plugin-istanbul for free as a last step in your babel pipeline.
If you're using typescript/coffeescript/whatever, we'll jest run these two as a second transformation step. Performance would suck, but will solve a lot of issues

@cpojer
Copy link
Member

cpojer commented Jul 13, 2016

It's definitely ok if we go down this route. I wouldn't mind for everything that doesn't use babel already.

At FB, we use our custom preprocessor and we need to make sure we don't double process there – what kind of escape-hatch can you think of for this use-case?

To summarize:

  • babel-jest should do coverage instrumentation and hoist Jest calls.
  • babel-jest will be used to transform coverage even when a different transformer is used.
  • when not using babel-jest, but you are not using a custom preprocessor that uses babel, like at FB, don't use babel-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 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants