Jest:moduleNameMapper: mocks do not work for imported modules of mapped modules using "moduleNameMapper"

[faceyspacey]

Issue description or question

If you map your modules in the Jest config file like this:

"moduleNameMapper": {
   "lazy&name=(.*)!": "<rootDir>/src/components/modals/$1.js"
}

And then one of your tests mocks a module used by a mapped module like this:

jest.mock('../src/widgets/Button', () => require('identity-obj-proxy'))

And then the mapped module you're testing imports Button like this:

/src/components/modals/file.js:

import Button from './Button

Button will NOT be mocked.

I've tested the regular scenario without using moduleNameMapper and the mock works just fine. Awesome! It only seems to break down when the moduleNameMapper dynamically chooses the module for you statically.

The hoisting-related issue and solution using babel-preset-jest does not solve that (that didn't do anything and you don't seem to need that anymore, as regular mocks work without it).

It just appears that wallaby is not able to discover mocks for your own files (or perhaps there's a special config I'm not privy to) when using the module mapper.

Also note: mocked NPM modules such as jest.mock('npm-module', () => require('identity-obj-proxy')) works just fine.

Wallaby.js configuration file

module.exports = function(wallaby) {
  return {
    files: [
      { pattern: 'src/**/*.js', load: false },
      { pattern: 'src/**/*.css', load: false, instrument: false },
      { pattern: 'src/**/*.styl', load: false, instrument: false },
      { pattern: 'package.json', load: false },
      { pattern: '__test-helpers__/**/*.js', load: false },
      { pattern: '__mocks__/**/*.js', load: false },
      { pattern: '__fixtures__/**/*.js', load: false },
      { pattern: '__tests__/**/*.snap', load: false },
    ],

    tests: ['__tests__/**/*.js'],

    env: {
      type: 'node',
      runner: 'node',
      params: {
        runner: '--harmony'
      }
    },

    testFramework: 'jest',
    compilers: {
      '**/*.js': wallaby.compilers.babel({babelrc: true, presets: ['babel-preset-jest']})
    },
    setup(wallaby) {
      wallaby.testFramework.configure(require('./package.json').jest)
    },
    debug: true
  };
};

Code editor or IDE name and version

Visual Studio Code v1.8

OS name and version

OSX

[ArtemGovorov]

Jest's <rootDir> points to the local project directory, and wallaby.js runs tests from its own file cache (where it has instrumented files), so when you do

"moduleNameMapper": {
   "lazy&name=(.*)!": "<rootDir>/src/components/modals/$1.js"
}

and later on import/require lazy&name=someFile!, the someFile is loaded from your local project (not instrumented).

You can easily fix it by using wallaby.js cache folder path in the config:

    ...
    setup: function (wallaby) {
      const conf = require('./package.json').jest
      const pattern = 'lazy&name=(.*)!'
      conf.moduleNameMapper[pattern] = conf.moduleNameMapper[pattern].replace('<rootDir>', wallaby.projectCacheDir)

      wallaby.testFramework.configure(conf)
    }

Let me know if this helps.

[faceyspacey]

wow that did it, thanks so much for your quick support! ...i by the way started using this and became a customer in one day--I couldn't be more impressed with the webpanel at http://wallabyjs.com/app/ . Very slick how you have it hosted from a URL on ur site. I wasn't expecting to click to it and see my own tests there!

...one other thing--cuz im not sure where to submit ideas--but basically Wallaby seems to be the perfect fit for Jest and its snapshot testing. It's a match made in heaven being able to browse your snapshots in a UI, rather than the command line (or after you commit code and can diff it). It allows u to diff code in a proper UI rather than in the terminal while you're editing. That said what would be perfect is if in the top right column of the web panel, the DIFF was shown by default rather than having to click that little icon in the top right and see it in a modal. After all, that's exactly what you want to see. The all red info of the failed result that you already have is obviously a lot harder to read. In addition, if you even showed successful snapshots, rather than just nothing, that would go a long way toward making Wallaby the defacto best (and only?) Jest snapshot browser--sometimes you just want to review how snapshots are looking; and if this was there, you'd be doing it a lot more often; it would become an effective part of you're workflow. To make it consistent with non-snapshots, just show the test file there too so you can click file names in the left column, and not have to perform a second click where you click the eye-ball. That would be a better overall user experience imho--because it would have you doing less switching of your attention from the wallaby panel and your editor. Why not just be instantly reminded of what tests are in each file, rather than having to click the eye-ball which you otherwise only do when you need to.

LAST THING: Add a button to update a snapshot right there in that top right box (so you don't have to run jest from the command line and annoyingly type out the testPathPattern of the file), and it's everything Jest is missing. You can now easily update a single snapshot, rather than worry you're updating too many by not specifying specific test patterns in the terminal. With all that, you've completed the Jest feedback loop!

I'm going to recommend everyone use Jest and Wallaby. Again, match made in heaven!

[ArtemGovorov]

@faceyspacey Wow, thanks for the feedback, I appreciate it!
We'll have a look into your suggestions, I like the ideas of improving the workflow for working with jest snapshots.

[faceyspacey]

@ArtemGovorov ...sorry to bother u again, one last thing: why no inline values within tests besides for console.log? Performance?

It's not a new idea at this point and I'm sure you're very aware of the idea--so that's why I'm assuming performance is the only reason you haven't done it--but basically if you guys had this (and tables containing values for loops), it would be the first useable implementation for javascript when not explicitly debugging, which itself has never been truly stable like it is in Chrome devtools. Like, the workflow you got here--rather, I got here now ;)--is utterly amazing, and very stable. It's the first time TDD in javascript UI work has made actual sense. It's just annoying to have to type console.log constantly, only to delete it, and if all the values were there u also get clues when when ur not explicitly looking for a value, i.e. before hunting down problems is even necessary.

If performance is the problem, maybe if just the current test function you're working on has values displayed, or ideally at least the currently focused/open file.

[ArtemGovorov]

@faceyspacey We did consider the idea early on, but the performance (everyone wants their tests to run as fast as possible), a lot of possible visual noise, inline message length limitations and a few other things are holding us off.

The performance can get really bad if doing the full trace values recording. Few years ago I have been doing it in spy-js and only for function params and return values, still had a significant performance impact.

For capturing just the latest values it can be pretty fast (see "Spy-js Magnifier"), but the approach has its own issues in the context of running unit tests.

With all this experience, we are now prototyping some best of both worlds lightweight debugging workflows, so may of the things you're asking may be covered there, so feel free to subscribe to that feature request and stay tuned :)

[ArtemGovorov]

what would be perfect is if in the top right column of the web panel, the DIFF was shown by default rather than having to click that little icon in the top right and see it in a modal

Done: https://twitter.com/wallabyjs/status/819121381002489856

[faceyspacey]

@ArtemGovorov that is absolutely excellent. it's working already for me. The way you deliver is by far the best/fastest I've ever seen. Something tells me it's because you're eating your own dogfood ;)