Provide a way to specify test environment setup file for Jest

My App is using localStorage but when I run tests, I get this error:

ReferenceError: localStorage is not defined

Should we provide a polyfill to be able to mock it with Jest ?

Workaround

Add a --setupTestFrameworkScriptFile ./localStoragePolyfill.js to the test command in package.json, where ./localStoragePolyfill looks like this:

const localStorageMock = (() => {
  let store = {}
  return {
    getItem(key) {
      return store[key]
    },
    setItem(key, value) {
      store[key] = value.toString()
    },
    clear() {
      store = {}
    }
  };
})()

global.localStorage = localStorageMock

I guess it should be added to config/polyfills.js.

I can PR if that's fine. Not sure if we should use a simple inline polyfill or use something like node-localstorage though.

@cpojer

Is there any reason you can't do this manually by importing a file like this from your test? Is it because many tests rely on this?

@cpojer What do you think is a reasonable solution? Should we come up with a conventional name for test setup file?

I definitely don't want to add mocks for this in CRA because there are hundreds of browser APIs people might need to mock in different ways. This should be controlled by the user.

Yeah, I think we should come up with a standard for CRA and if the file exists, it gets added to setupFiles, just like we talked about.

For localStorage mocking, it probably needs a mock that uses ES proxies :)

@gaearon

@gaearon I can indeed directly import the polyfill just before importing my file in the test. However, because localStorage is in the global scope, I don't know if we can rely on the order in which the files are imported, I thought it was safer to import it using the setupFiles option.

Can we rely on the fact that import statements are executed in order ? Is this a standard ?

Yes, order matters for ES imports.

@gaearon

The thing is, --setupTestFrameworkScriptFile should really be deprecated or renamed and we should either expose --setupFile=<path> (which can be array arguments?) to add new setup files or do what @gaearon said and look for a setup file in a standard location.

tbh I'm happy to even support this directly in Jest. We could look for <rootDir>/.jest-setup.js.

Is src/index.test.js going to be confusing? I’m asking because we already have src/index.js as required file so it makes sense to “anchor” test setup around it.

Yeah I don't think that will work well as an automatic default tbh. Especially since right now it would be run as a test itself.

src/setupTests.js

I don't want to make an assumption either about folder structure or whether to use camelcase or anything inside of their actual code. I'd be happy to support jest-setup.js or .jest-setup.js in the root automatically. I think anything else I'd recommend you to do in CRA on top :)

Yeah, I meant doing this in CRA config. Since CRA already asks src/index.js to exist we can have more conventional names here, as this makes sense given nature of the project.

Absolutely, feel free to make any call that you think is best for CRA users and decouple it from a similar setting in Jest we may want to add.

Does Jest fail if passed file doesn’t exist?

Yeah it'll fail. A silent error for a setup file wouldn't be very useful I think.

This makes sense. I propose the following: if src/setupTests.js exists it should be used, otherwise we don’t pass it. This logic would live in createJestConfig.js. Path itself would be determined in paths.js.

@gaelduplessix Would you like to submit a PR implementing this?

Add src/setupTests.js to specify environment setup for Jest (#545) (#548

Thanks for fixing this!

Add src/setupTests.js to specify environment setup for Jest (react#545)…

#1990

Navigation Menu

Repository navigation

Provide a way to specify test environment setup file for Jest #545

Workaround

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Provide a way to specify test environment setup file for Jest #545

Description

Workaround

Activity

gaearon commented on Sep 2, 2016

gaearon commented on Sep 2, 2016

cpojer commented on Sep 2, 2016

gaelollivier commented on Sep 2, 2016

cpojer commented on Sep 2, 2016

cpojer commented on Sep 2, 2016

gaearon commented on Sep 2, 2016

cpojer commented on Sep 2, 2016

gaearon commented on Sep 2, 2016

cpojer commented on Sep 2, 2016

gaearon commented on Sep 2, 2016

cpojer commented on Sep 2, 2016

gaearon commented on Sep 2, 2016

cpojer commented on Sep 2, 2016

gaearon commented on Sep 2, 2016

2 remaining items

gaearon commented on Sep 2, 2016

ebrentnelson commented on Apr 27, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions