Skip to content

Jest

Starting Wallaby on a project with configured Jest

To start Wallaby in VS Code you may run Select Configuration command and then select Automatic Configuration <project directory> option once. After that you may keep using Wallaby Start command as usual and it will start Wallaby with automatic configuration.

To start Wallaby in Sublime Text you may use the Select for Wallaby.js Automatic Configuration context menu item for your project folder in the project’s file tree. After that you may keep using Wallaby Start command as usual and it will start Wallaby with automatic configuration.

To start Wallaby in Visual Studio, you may use the Start Wallaby.js (Automatic Configuration) context menu item for your project folder in the Solution Explorer. After the first start, the selected project will be remembered for your solution and Wallaby can be started with Tools->Start Wallaby.js (Alt-W, 1).

To start Wallaby in JetBrains IDEs, you may edit (or create a new) wallaby.js Run Configuration by selecting Edit configurations from the drop-down menu in the top right-hand corner of the navigation bar, or from the Run menu. In the run configuration editor set Configuration Type filed value to Automatic.

Overriding Automatic Configuration

Sometimes you may want to add/override some Wallaby configuration settings to the automatically detected settings. For example, if you are not using jest’s default configuration file naming convention (i.e. jest.config.js in your project root), or if jest exists outside of your project’s default node_modules directory (e.g. @microsoft/rush) then you may configure these locations by specifying a configuration file or package.json section.

After creating Wallaby config file to override automatic defaults in VS Code you need to run Select Configuration command and then select the config file once. After that you may keep using Wallaby Start command as usual and it will start Wallaby with the configuration file.

After creating Wallaby config file to override automatic defaults in JetBrains IDEs, you may edit (or create a new) wallaby.js Run Configuration by selecting Edit configurations from the drop-down menu in the top right-hand corner of the navigation bar, or from the Run menu. In the run configuration editor set Configuration Type filed value to Configuration File.

For example, to use Jest auto-configuration with a custom Jest config path, you may create the following Wallaby config file in your project’s root:

wallaby.js

module.exports = () => {
  return {
    testFramework: {
      // the jest configuration file path
      // (relative to project root)
      configFile: './jest.config.wallaby.js',
    },
  };
};

Or, if jest exists outside of your project’s default node_modules directory, you may specify its path:

wallaby.js

module.exports = () => {
  return {
    testFramework: {
      // the path to locate jest
      // (relative to project root)
      path: './subfolder/node_modules',
    },
  };
};

If you don’t want to create Wallaby config file, you may use package.json wallaby section:

package.json

{
  "wallaby": {
    "testFramework": {
      "configFile": "./jest.config.walllaby.js"
    }
  }
}

Note that if you are adding/overriding files/tests, then it is required to add the autoDetect: true setting:

module.exports = () => ({
  autoDetect: true,
  files: [...],
  tests: [...],
});

Snapshot testing

It’s recommended to read the article about Jest snapshot testing workflow with wallaby.js. Amongst other things, the article describes how to update individual test snapshots:

ECMAScript Modules

Jest supports ES modules but requires you to pass the --experimental-vm-modules flag to Node.js.

To run Jest with Wallaby and ES modules, you will either need to add wallaby section that sets the required node flag to your package.json file:

package.json

{
  ...
  "wallaby": {
    "env": {
      "params": {
        "runner": "--experimental-vm-modules"
      }
    }
  }
}

or to create and use a small wallaby.js configuration file:

wallaby.js

export default function () {
  return {
    env: {
      params: {
        runner: '--experimental-vm-modules',
      },
    },
  };
}

Note that the config file has to be ES module if your package.json has the "type": "module" setting.

Node settings

Node version

If you’d like to use your system default node.js version or any specific locally installed version instead of using the version configured for your IDE or editor, use the env.runner property to specify a command to invoke node or a path to a node executable.

module.exports = function () {
  return {
    ...
    env: {
      runner: 'node', // or full path to any node executable
    },
  };
};

Node flags

If you need to pass some node flags, such as --harmony, you may use env.params.runner property for that:

module.exports = function () {
  return {
    ...


    env: {
      params: {
        runner: '--harmony --harmony_arrow_functions',
      },
    },
  };
};

Environment variables

If you need to pass some process.env variables to the test environment, you may just set them right in the wallaby config file:

module.exports = function () {


  process.env.NODE_ENV = 'development';


  return {
    ...
  };
};

Alternatively, you may use env.params.env property for it:

module.exports = function () {
  return {
    ...


    env: {
      params: {
        env: 'NODE_PATH=/a/b/c;HOME=/Users/a/b',
      },
    },
  };
};

Node process reuse

When running your node.js tests, wallaby by default tries to re-use previously created node.js process(es) to make the runs faster. If you are relying on the test node process re-start for each run, because your tests are not cleaning after themselves (for example, they are not closing opened database connections, not stopping started web services, or are registering some callbacks that may be invoked after your test run finishes and interfere with your next test run), then you may use workers.restart setting set to true to make wallaby.js re-start node process for each run.

module.exports = function () {
  return {
    ...


    workers: {
      restart: true,
    },
  };
};

Whether you use the setting or not, you will still benefit from wallaby.js incremental test run feature compared to the normal test runner. However, while using the setting allows you to rely on the process re-start and avoid writing any cleanup code, we recommend that you consider adding clean-up code and not recycling node workers, as wallaby.js will be able to run your tests even faster if node processes are reusable.

Node process count

By default, wallaby.js automatically decides how many processes to use to run your tests in parallel based on your system capacity. However, sometimes you may need to manually set the number of workers to be used. For example, if your tests are creating an HTTP server that is listening on a certain port (as opposed to using dynamic port allocation for your tests), you may need to set the workers count to 1, because otherwise you may have issues with different test workers trying to create the server on the same port.

module.exports = function () {
  return {
    ...




    workers: {
      initial: 1,
      regular: 1,
    },
  };
};

A better approach would be to dynamically allocate ports, so that your tests could run in parallel.

Troubleshooting

When configured to run using automatic configuration, Wallaby runs in Jest’s execution pipeline. Wallaby will return the same results and code coverage as you would get when running Jest from the command-line.

The first step of troubleshooting a project configured to use automatic configuration is to identify whether the same results are returned using npx jest. Running Jest from the command-line will usually show/highlight the cause of your problem.

You may also try clearing Jest’s cache using: npx jest --clearCache.

If you continue to have problems, please try manually clearing Jest’s cache and reinstalling Wallaby’s core runtime:

  1. Identify the cache location using npx jest --showConfig and identifying the cache location from the config key: cacheDirectory.
  2. Delete the folder specified in cacheDirectory.
  3. Follow these steps to force a core runtime update.

If you get stuck or something isn’t working for you, you may find further troubleshooting steps here or else find a similar solved issue in our github issues repository. If you can’t find a solution, create a new issue.