jest: globalSetup and globalTeardown are ignored in projects.

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

What is the current behavior? globalSetup and globalTeardown are ignored when they are defined inside a project.

If the current behavior is a bug, please provide the steps to reproduce I’m using the following jest.config.js:

module.exports = {
  projects: [
    {
      displayName: 'unit',
      testMatch: ['<rootDir>/src/**/*.spec.ts'],
      transform: {
        "^.+\\.ts$": "ts-jest"
      },
      moduleDirectories: ["node_modules", "./"],
      moduleFileExtensions: ["ts", "js", "json", "node"]
    },
    {
      displayName: 'e2e',
      testMatch: ['<rootDir>/e2e/**/*.spec.ts'],
      transform: {
        "^.+\\.ts$": "ts-jest"
      },
      moduleDirectories: ["node_modules", "./"],
      moduleFileExtensions: ["ts", "js", "json", "node"],
      globalSetup: '<rootDir>/e2e/global-setup.js',
      globalTeardown: '<rootDir>/e2e/global-teardown.js'
    }
  ]
};

What is the expected behavior? I’m not sure if this is an expected behaviour or not. However, whey I try to use a non-existing file for a globalSetup / globalTeardown, then it throws the following error:

Validation Error:
Module .../e2e/global-setup.js in the globalSetup option was not found.

So, Jest is expecting an option like this in project.

Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system. Jest: v22.1.4 Node: v8.9.4 OS: macOS High Sierra

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 22
Comments: 17 (7 by maintainers)

Most upvoted comments

@mariogintili I started implementing the hacky way to do that, realizing it would be fairly easy to implement properly in Jest. We can call it projectSetup/projectTeardown, it would work like globalSetup/globalTeardown for a specific project.

Here an example:

projectsetup

Some use the projects feature for running different environments/runners in the same module while other for multiple modules in a monorepo. Maybe we can stick with the names globalSetup/globalTeardown which will work as displayed above?

@thymikee @SimenB what do you think?

ranyitz on Aug 16, 2018

Also having this problem when trying to run some test files with jest-puppeteer, and other test files with jsdom. Any workarounds?

t-kelly on May 31, 2018

@ctrlplusb If I understand correctly you’d like to run only the relevant globalSetup/globalTeardown according to the tests that you’re going to run at the moment.

A workaround would be to create a top-level globalSetup and globalTeardown that do different things (or call other globalSetup files) according to the tests that should be run. You’ll get jest’s globalConfig as a parameter and could use values from it against each project’s testMatch/testRegex. I know it’s not a perfect solution but it might just do the trick.

I think a good solution would be to run a project’s globalSetup file only if we run at list one test from this project. So devs could write setup code that relates to a certain type of tests. For example, you don’t need to bootstrap puppeteer if you don’t have any e2e test to run at the moment.

ranyitz on Aug 15, 2018

Also, I find out that globalSetup and globalTeardown are ignored when you use jest --projects packages/foo in yarn workspaces. Even when setup and teardown from foo package are not wrapped in “projects” property.

So, basically the same error: setup and teardown are ignored if they are required by project. Using a jest --projects is just another way how to “wrap” them into a project.

In another words: globalSetup and globalTeardown in any package are ignored when you try to run jest on multiple packages using –projects flag.

deftomat on Feb 5, 2018

A workaround would be to create a top-level globalSetup and globalTeardown that do different things (or call other globalSetup files) according to the tests that should be run. You’ll get jest’s globalConfig as a parameter and could use values from it against each project’s testMatch/testRegex. I know it’s not a perfect solution but it might just do the trick.

I inspected the globalConfig argument, but how can I see what the current (running) project is?

I need to be able to start the mongodb-memory-server only for the integration tests. Not for running unit tests. I thought having a project for integration tests and one for unit tests, with both their own testEnvironment with corresponding setup and teardown scripts, would be able to provide this for me. But if I understand correctly, that’s currently not possible.

smeijer on Oct 7, 2018