Use Jest muti-project runner instead of a global config

[tylersmalley]

Jest tests are currently split into a few non-standard configurations injected through Node CLI scripts:

scripts/jest.js:

• https://github.com/elastic/kibana/blob/master/src/dev/jest/config.js (time: 12:40)
• Integration: https://github.com/elastic/kibana/blob/master/src/dev/jest/config.integration.js (time: 15:38)

x-pack/scripts/jest.js:

• https://github.com/elastic/kibana/blob/master/x-pack/dev-tools/jest/create_jest_config.js (time: 55:04)
• Integration: https://github.com/elastic/kibana/blob/master/x-pack/test_utils/jest/config.integration.js (not running, no tests)

There are a few reasons this is not ideal. Mainly, it has led to confusion to how Jest works for those otherwise familiar with it. In addition, we loose any benefits to tooling available which requires running Jest directly or referencing a configuration file.

Another issue we have is these configurations cover a vast amount of tests across large portions of the repository. Currently, the X-Pack Jest tests take an hour to complete on CI. This results in contributors temporarily using .only within their tests, or specifying --testPathPattern. This really starts to break down when you would like to run all the tests for your plugin as you have to rely on naming convention which might change plugin-to-plugin.

I propose we move to a having a base Jest configuration file which each plugin could extend, and a core jest.config.js file which defines a pattern for projects to cover those configuration files.

This will still allow for the entire suite of tests to be ran for CI while allowing contributors to run the unit tests of their plugin in isolation.

TODO:

• See if we can reduce memory requirements for Jest tests

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[spalger]

I don't think --testPathPattern is a very good way to limit the tests that run. It's much more straightforward to copy a specific file path or use tab-completion to type a directory prefix and pass it as an unnamed arg to any jest CLI ie node scripts/jest src/core/server. Do we know if this will still work with jest projects?

I think ultimately it would be ideal to schedule the jest suites using CI tasks rather than jest projects, mostly so we can execute them on multiple workers. That said we don't have CI tasks yet but it shouldn't be long. Additionally though, CI tasks are defined in groovy and we probably need to make sure that we're validating that all jest configs are included in some manifest that the pipeline code can rely on being up to date...

[tylersmalley]

• Add validation to error on test files not covered by a jest configuration file and/or ran on CI.