setupTestFrameworkScriptFile option is missing

[just-boris]

Hello!
There is a convention to autoload src/setupTests.js file to set up the test environment, but it doesn't allow to load extra matchers for Jasmine.

I have some library with good extra matchers like jasmine-enzyme and it is supposed to be included as setupTestFrameworkScriptFile, which it not possible to do now.

[gaearon]

cc @cpojer, I don’t know anything about this

[cpojer]

@gaearon setupFiles are loaded before anything else in the context, setupTestFrameworkScriptFile is loaded after jasmine so it is a good way to influence the test environment. We'll soon expose expect.extend in Jest and there is an open issue tracker on our repo for this but I believe this issue is simply asking for a way to provide a setup file for the test env. Can somebody send a PR for this?

[gaearon]

Does Jest intend to support jasmine-enzyme compatibility? I wouldn’t want to add support for something if Jest plans to change its extension mechanism soon.

[gaearon]

setupFiles are loaded before anything else in the context, setupTestFrameworkScriptFile is loaded after jasmine so it is a good way to influence the test environment

Would this distinction be useful to our users? Wouldn’t it be better to make src/setupTests.js act as setupTestFrameworkScriptFile then?

[just-boris]

I think so. It would be more helpful when setupTests.js will behave like setupTestFrameworkScriptFile.

As a user, I don't see any use case to run some code before test framework. Usually, I need to set up something via API that framework provides (which definitely should be after framework init), or mocking some global APIs, like localStorage in the example in documentation which also can be done regardless test framework initialization.

[cpojer]

See https://github.com/blainekasten/jasmine-enzyme/issues/39

We have some constraints at FB where we want certain files to be loaded before the test framework (env, polyfills etc.) and certain files after (to add to Jasmine).

In the near future it should be enough to call expect.extend from within a setupFiles in Jest. Once jasmine-enzyme gets renamed to jest-enzyme and once it supports our new, future API, it can be hooked in in a setup file.

[just-boris]

@cpojer Even if special matchers API will be exposed, will it be available at setupFiles? If no, the question how to use this in CRA remains open.

@gaearon getting back to the general topic, do you mind to put src/setupTests file to setupTestFrameworkScriptFile instead of current place? CRA takes care about polyfilling by itself, so existing use-cases will not be broken, but it will make possible to use extensions that rely on Jasmine/Jest api.

[cpojer]

Yes it'll be possible to extend expect from setupFiles. I'm not sure it's a good idea to move this around in cra right now if we end up moving it back later.

[just-boris]

As far as I see, recently released Jest 16 doesn't have this change. @cpojer do you have any estimation when it will become available?

@gaearon nevertheless, I found another issue with current setupTests behavior. I can't define global expect function, it is being overwritten by Jest. I'd like to have this

import expect from 'expect'; //here also can be chai, doesn't matter

expect.extend({/* my extra matchers */});

global.expect = expect;

I'd like to define expect only once and then use it everywhere in my tests without explicit import, but it doesn't work.

So, anyway setupTestFrameworkScriptFile looks like a better extension point, even it has such a weird name.

[gaearon]

@cpojer Are there any downsides to using setupTestFrameworkScriptFile in CRA?

[cpojer]

I guess it should be fine.

[gaearon]

@just-boris Want to make a PR?

[just-boris]

Yes, I can do.
I already did some related commits into my fork just-boris@27d99d1 I will update it to actual state and will send a PR