Allow more control over jest configuration

[jeff-kilbride]

As stated in https://github.com/AnomalyInnovations/serverless-bundle/issues/55#issuecomment-588051621 -- the current way the configuration for jest is built, based on the create-react-app model, is very restrictive. There are many options it would be nice to have available when running npm test from serverless-bundle. For example, verbose and bail are two I use frequently, but they are not available in the list of supported options.

Currently, serverless-bundle allows more control over users eslint configurations by honoring an .eslintrc file (or any of the permutations) in the root directory. Maybe it would be possible to also honor a jest.config.js file, if it exists.

Thanks!

[jayair]

Yeah that makes sense. Is there something comparable out there? So we could piggyback on their design of jest.config.js?

[jeff-kilbride]

There's a serverless-jest-plugin -- but I've never used it and don't know how good or up-to-date it is. However, it might provide some insight. I haven't written any serverless plugins, so it might be easier for you to understand glancing at the code. It may be as easy as removing the jest stuff from serverless-bundle and including this as another plugin, like serverless-offline and serverless-dotenv-plugin. Or it might involve forking it and cleaning it up / updating it to work correctly.

Jest is advertised as zero config for most applications, which is more true than not. It typically works out of the box, but has lots of options for anyone who wants to tweak it. Are there things you are doing in the current createJestConfig.js file that couldn't be included in a normal jest.config.js? When run from the command line, jest will find it's config automatically if it exists. So, the question is, does the config have to be built dynamically or could you provide a default jest.config.js that accomplishes the same thing? Anybody who wanted to tweak it could just edit that default config file.

[jeff-kilbride]

Honestly, another idea would be to add the rest (or majority) of the jest configuration options to the list of supportedKeys in the current createJestConfig.js. I don't think the way you're doing it, right now, is necessarily bad -- just too restrictive. There are lots of options that could be supported, just by extending that list of supportedKeys.

[jayair]

Hmmm let me quickly get a sense of which options you are currently looking for?

[patrykkrawczyk]

Hi @jayair , bumping this issue since I have this problem too. I'd like to write tests and use dynamodb as described here https://jestjs.io/docs/en/dynamodb Therefore I would need to change preset is there any progress on this?

[patrykkrawczyk]

I've actually added a small PR for this https://github.com/AnomalyInnovations/serverless-bundle/pull/101 Edit: nevermind, found a workaround, closed PR

[FlorentPaillot]

I also had an issue related to Jest not working properly with Mongoose (see details below as well as a workaround). The fix could also benefit other projects as well because there is a setting that IMHO should be set permanently, which is to set Jest config variable "testEnvironment" to "node" instead of the default value "jsdom" meant for a different development environment.

In details, for my project, my functions need to access data from MongoDB. I use Mongoose to model my schemas. I wrote a simple test to check the 200 status code. After running it, I get this message:

$ npm test console.warn ../../node_modules/mongoose/lib/helpers/printJestWarning.js:4 Mongoose: looks like you're trying to test a Mongoose app with Jest's default jsdom test environment. Please make sure you read Mongoose's docs on configuring Jest to test Node.js apps: http://mongoosejs.com/docs/jest.html
[...]

From the page above, it is said:

Do not use Jest's default jsdom test environment when testing Mongoose apps, unless you are explicitly testing an application that only uses Mongoose's browser library.

And from the Jest's documentation related to the "testEnvironment" config variable:

testEnvironment [string] Default: "jsdom"

The test environment that will be used for testing. The default environment in Jest is a browser-like environment through jsdom. If you are building a node service, you can use the node option to use a node-like environment instead.

With all that be said, it seems that "testEnvironment" should be set to "node" in the serverless-bundle package.

Regarding the workaround, just after the statement above, the doc says:

By adding a @jest-environment docblock at the top of the file, you can specify another environment to be used for all tests in that file:

/**
 * @jest-environment jsdom
 */

test('use jsdom in this test file', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

That what worked for me, but it would be better, at least, to be able to set that variable either in a "jest.config.json" file or in "package.json", which is not possible because serverless-bundle doesn't support it:

$ npm test

> [email protected] test C:\Users\Florent\sandbox\dev\project\services\that-api > node ../../node_modules/.bin/serverless-bundle test

Out of the box, serverless-bundle only supports overriding these Jest options:

• collectCoverageFrom • coverageReporters • coverageThreshold • extraGlobals • globalSetup • globalTeardown • reporters • resetMocks • resetModules • setupFilesAfterEnv • snapshotSerializers • testResultsProcessor • transform • transformIgnorePatterns • watchPathIgnorePatterns.

These options in your package.json Jest configuration are not currently supported by serverless-bundle:

• testEnvironment

If you wish to override other Jest options, consider using serverless-webpack directly instead.

[jayair]

@FlorentPaillot Oh that's a good point. I haven't had a chance to look at this in detail but if we can set it to Node instead, can we do that? If so then please submit a PR!

[oakgary]

is there a reason why the list of supportkeys is not equivalent to jests configuration options?

it would also be nice if one could define the environment variables loaded by jest the script currently loads the .env file https://github.com/AnomalyInnovations/serverless-bundle/blob/master/scripts/config/createJestConfig.js#L100 which is also the default for the serverless dotenv plugin https://www.npmjs.com/package/serverless-dotenv-plugin which could lead to accidentally loading prod envs into tests we could change it to something like .env.test or .env.jest or make the path an option

[jayair]

We started by supporting the configuration options from Create React App and added the ones folks requested.

Yeah by default we load the .env file. Whats the issue you are running into with loading prod envs for your tests?

[oakgary]

The problem is, that the dotenv-plugin will use the .env file as default as well. So if I use the .env file for my production environment and now add tests, the tests will load the same variables, which can have unintended side effects. It would be nice if I could put the environment variables for tests in a separate file.

[jayair]

@oakgary That makes sense. I'd like to do some quick research on how similar projects deal with this issue. Do you mind helping with that? I'd like to check projects like Create React App or maybe Next.js for how they handle this.

[andrey-k]

@patrykkrawczyk what kind of workaround did you find? I also would like to use https://jestjs.io/docs/en/dynamodb

I'd like to write tests and use dynamodb as described here https://jestjs.io/docs/en/dynamodb

[codan84]

I am facing similar issue. For some reason I can't override testPathIgnorePatterns. I want to be able to run certain tests (unit or integration) separately. To do this I wanted to leverage this cli option by doing something like this in package.json:

"test:unit": "serverless-bundle test -- --testPathIgnorePatterns=src/test",
"test:integration": "serverless-bundle test -- --testPathPattern=src/test",

[mattxwang]

Hey, just wanted to circle back on this issue - @jayair did you have a chance to take a peek at different projects implementations?

Honestly, another idea would be to add the rest (or majority) of the jest configuration options to the list of supportedKeys in the current createJestConfig.js

In the meantime, I'm more than happy to submit a quick PR here - Create React App has updated their list of supportedKeys since the one in this repo was created, so more than happy to start from there. I'm personally looking to add restoreMocks if possible!