4e8ab56497
* build immutable bundles for new platform plugins * only inspect workers if configured to do so * [navigation] use an index.scss file * add yarn.lock symlink * set pluginScanDirs in test so fixtures stay consistent * cleanup helpers a little * fix type error * support KBN_OPTIMIZER_MAX_WORKERS for limiting workers via env * test support for KBN_OPTIMIZER_MAX_WORKERS * expand the available memory for workers when only running one or two * add docs about KBN_OPTIMIZER_MAX_WORKERS environment variable * fix README link * update kbn/pm dist * implement bundle caching/reuse * update kbn/pm dist * don't check for cache if --no-cache is passed * update renovate config * standardize on index.scss, move console styles over * add support for --no-cache to cli * include worker config vars in optimizer version * ignore concatenated modules * update integration test * add safari to browserslist to avoid user-agent warnings in dev * update docs, clean up optimizer message/misc naming * always handle initialized messages, don't ignore states that are attached to specific events * reword caching docs, add environment var to disable caching * tweak logging and don't use optimizer.useBundleCache as that's disabled in dev * handle change notifications * batch changes for 1 second * rename CompilerState type to CompilerMsg * getChanges() no longer needs to assign changes to dirs * remove unused deps * split up run_worker.ts and share cacheKey generation logic * add a couple docs * update tests and remove unused imports * specify files when creating bundle cache key * remove one more unused import * match existing dev cli output more closely * update kbn/pm dist * set KBN_NP_PLUGINS_BUILT to avoid warning in CI * avoid extending global window type * add note to keep pluginScanDirs in sync * pass browserslistEnv in workerConfig so it is used for cache key * load commons.bundle.js in parallel too * emit initialized+success states if all bundles are cached * load bootstraps as quickly as possible * skip flaky suite * bump * update jest snapshots * remove hashing from cache key generation * remove unnecessary non-null assertion * improve docs and break up Optimizer#run() * remove unused import * refactor kbn/optimizer to break up observable logic, implement more helpful cache invalidation logic with logging * fix tests * add initializing phase * avoid rxjs observable constructor * remove unnecessary rxjs helper, add tests for bundle cache * update consumers of optimizer * update readme with new call style * replace "new platform" with "kibana platform" * fix a couple more renames * add support for several plain-text file formats * fix naming of OptimizerMsg => OptimizerUpdate, use "store" naming too * one more OptimizerMsg update * ensure bundles are not cached when cache config is false * test for initializing states and bundle cache events * remove unnecessary timeout change * Remove unnecessary helpers * Add tests for BundleCache class * Add tests for Bundle class * test summarizeEvent$ * missing paths are no longer listed in mtimes map * add tests for optimizer/cache_keys * Add some extra docs * Remove labeled loop * add integration test for kbn-optimizer watcher components * querystring-browser removed * tweak logging a smidge, improve info and final message * remove unused imports * remove duplication of getModuleCount() method * move type annotation that validates things * clear up the build completion message Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| src | ||
| types | ||
| babel.config.js | ||
| index.d.ts | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
| yarn.lock | ||
Kibana Testing Library
The @kbn/test package provides ways to run tests. Currently only functional testing is provided by this library, with unit and other testing possibly added here.
Functional Testing
Dependencies
Functional testing methods exist in the src/functional_tests directory. They depend on the Functional Test Runner, which is found in {KIBANA_ROOT}/src/functional_test_runner. Ideally libraries provided by kibana packages such as this one should not depend on kibana source code that lives in {KIBANA_ROOT}/src. The goal is to start pulling test and development utilities out into packages so they can be used across Kibana and plugins. Accordingly the Functional Test Runner itself will be pulled out into a package (or part of a package), and this package's dependence on it will not be an issue.
Exposed methods
runTests(configPaths: Array)
For each config file specified in configPaths, starts Elasticsearch and Kibana once, runs tests specified in that config file, and shuts down Elasticsearch and Kibana once completed. (Repeats for every config file.)
configPaths: array of strings, each an absolute path to a config file that looks like this, following the config schema specified here.
Internally the method that starts Elasticsearch comes from kbn-es.
startServers(configPath: string)
Starts Elasticsearch and Kibana servers given a specified config.
configPath: absolute path to a config file that looks like this, following the config schema specified here.
Allows users to start another process to run just the tests while keeping the servers running with this method. Start servers and run tests using the same config file (see how).
Rationale
Single config per setup
We think it makes sense to specify the tests to run along with the particular server configuration for Elasticsearch and Kibana servers, because the tests expect a particular configuration. For example, saml api integration tests expect certain xml files to exist in Elasticsearch's config directory, and certain saml specific options to be passed in via the command line (or alternatively via the .yml config file) to both Elasticsearch and Kibana. It makes sense to keep all these config options together with the list of test files.
Multiple configs running in succession
We also think it makes sense to have a test runner intelligently (but simply) start servers, run tests, tear down servers, and repeat for each config, uninterrupted. There's nothing special about each kind of config that specifies running some set of functional tests against some kind of Elasticsearch/Kibana servers. There doesn't need to be a separate job to run each kind of setup/test/teardown. These can all be orchestrated sequentially via the current runTests implementation. This is how we envision tests to run on CI.
This inherently means that grouping test files in configs matters, such that a group of test files that depends on a particular server config appears together in that config's testFiles list. Given how quickly and easily we can start servers using @kbn/es, it should not impact performance to logically group tests by domain even if multiple groups of tests share the same server config. We can think about how to group test files together across domains when that time comes.