kibana/packages/kbn-test
Tiago Costa 20bdf7d4a9
Migration to Babel7 and @babel/preset-typescript (#33093)
* chore(NA): first changes on every package.json order to support new babel 7. chore(NA): build for kbn-pm with babel 7.

* chore(NA): patch babel register to load typescrit

* chore(NA): first working version with babel 7 replacing typescript compiler.

* fix(NA): common preset declaration in order to make it work with babel-loader.

* chore(na): organizing babel preset env package json.

* chore(NA): mocha tests enabled.

* fix(NA): typo on importing

* test(NA): majority of x-pack tests ported to use babel-jest

* fix(NA): report info button test with babel-jest.

* fix(NA): polling service tests.

* test(na): fix server plugins plugin tests.

* test(NA): batch of test fixs for jest tests under babel-jest hoisting.

* chore(NA): add babel plugin to hoist mock prefixed vars on jest tests.

* chore(NA): update yarn.lock file.

* chore(NA): tests passing.

* chore(NA): remove wrong dep

* chore(NA): fix tsconfig

* chore(NA): skip babel for ts-jest.

* chore(NA): selectively apply the plugin to strip off namespace from ts files.

* chore(NA): remove not needed changes from ts tests

* chore(NA): removed ts-jest dependency. chore(NA): migrate ts tests on x-pack to use babel-jest with the new pattern.

* chore(NA): migrate kibana default distribution typescript tests to run with babel-jest and the new test mock pattern.

* chore(NA): merge and solve conflicts with master.

* chore(NA): fix problems reported by eslint

* chore(NA): fix license ovveride for babel-plugin-mock-imports

* chore(NA): update jest integration tests for kbn pm

* chore(NA): update babel jest integration tests for kbn pm.

* test(NA): update jest integration snapshot for kbn pm.

* chore(NA): apply changes according to the pull request reviews.

* chore(NA): apply changes according to the pull request reviews.

* refact(NA): migrate jest tests to the new pattern.

* fix(NA): babel 7 polyfill in the tests bundle.

* chore(NA): restore needed step in order to compile x-pack with typescript.

* chore(NA): change build to compile typescript with babel for the oss code. chore(NA): change transpile typescript task to only transpile types for x-pack. refact(NA): common preset for babel 7

* Revert "chore(NA): change build to compile typescript with babel for the oss code. chore(NA): change transpile typescript task to only transpile types for x-pack. refact(NA): common preset for babel 7"

This reverts commit 2707d538f5.

* fix(NA): import paths for tabConfigConst

* chore(NA): fix transpiling error on browser tests

* chore(NA): simplify kbn babel preset package.

* chore(NA): migrate build to use babel transpiler for typescript excluding xpack.

* fix(NA): introduced error on test quick task.

* fix(NA): fix preset for client side code on build.

* fix(NA): build with babel

* fix(NA): negated patterns in the end.

* fix(NA): kbn_tp_sample_panel_action creation.

* fix(NA): babel typescript transform plugin workaround when exporting interface name.

* refact(NA): remove not needed type cast to any on jest test.

* docs(NA): add developement documentation about jest mocks test pattern.

* chore(NA): missing unmerged path.

* chore(NA): fix jest tests for template.

* [CCR] Client integration tests (table lists) (#33525)

* Force user to re-authenticate if token refresh fails with `400` status code. (#33774)

* Improve performance of the Logstash Pipeline Viewer (#33793)

Resolves #27513.

_This PR is a combination of #31293 (the code changes) + #33570 (test updates). These two PRs were individually reviewed and merged into a feature branch. This combo PR here simply sets up the merge from the feature branch to `master`._

Summary of changes, taken from #31293:

## Before this PR
The Logstash Pipeline Viewer UI would make a single Kibana API call to fetch all the information necessary to render the Logstash pipeline. This included information necessary to render the detail drawer that opens up when a user clicks on an individual vertex in the pipeline.

Naturally, this single API call fetched _a lot_ of data, not just from the Kibana server but also, in turn, from Elasticsearch as well. The "pro" of this approach was that the user would see instantaneous results if they clicked on a vertex in a pipeline and opened the detail drawer for that vertex. The "cons" were the amount of computation Elasticsearch had to perform and the amount of data being transferred over the wire between Elasticsearch and the Kibana server as well as between the Kibana server and the browser.

## With this PR
This PR makes the Kibana API call to fetch data necessary for **initially** rendering the pipeline — that is, with the detail drawer closed — much lighter. When the user clicks on a vertex in a pipeline, a second API call is then made to fetch data necessary for the detail drawer.

## Gains, by the numbers

Based on a simple, 1-input, 1-filter, and 1-output pipeline.

* Before this PR, the Elasticsearch `logstash_stats` API responses (multiple calls were made using the `composite` aggregation over the `date_histogram` aggregation) generated a total of 1228 aggregation buckets (before any `filter_path`s were applied but across all `composite` "pages"). With this PR, the single `logstash_stats` API response (note that this is just for the initial rendering of the pipeline, with the detail drawer closed) generated 12 buckets (also before any `filter_path`s were applied). That's a **99.02% reduction** in number of buckets.

* Before this PR, the Elasticsearch `logstash_stats` API responses added up to 70319 bytes. With this PR, the single `logstash_stats` API response for the same pipeline is 746 bytes. That's a **98.93% reduction** in size.

* Before this PR, the Elasticsearch `logstash_state` API response was 7718 bytes. With this PR, the API response for the same pipeline is 2328 bytes. That's a **69.83% reduction** in size.

* Before this PR the Kibana API response was 51777 bytes. With this PR, the API response for the same pipeline is 2567 bytes (again, note that this is just for the initial rendering of the pipeline, with the detail drawer closed). That's a **95.04% reduction** in size.

* [Maps] split settings into layer and source panels (#33788)

* [Maps] split settings into layer and source panels

* fix SCSS import

* [env] exit if starting as root (#21563)

* [env] exit if starting as root

* fix windows

* s/--allow-root

* Typescript sample panel action (#33602)

* Typescript sample panel action

* Update EUI version to match main cabana version

* update yarn.lock

* add back typings include

* use correct relative path

* Home page "recent links" should communicate saved object type #21896 (#33694)

* adds object type for screen order
* adds object type for pointer hovering
* Update src/legacy/ui/public/chrome/directives/header_global_nav/components/header.tsx

Co-Authored-By: rockfield <philipp.b@ya.ru>
2019-03-26 20:44:03 +00:00
..
src Refactor ES-related environment variables (#33036) 2019-03-13 11:51:06 -07:00
types [@kbn/expect] "fork" expect.js into repo (#33761) 2019-03-25 09:56:48 -07:00
babel.config.js Migration to Babel7 and @babel/preset-typescript (#33093) 2019-03-26 20:44:03 +00:00
package.json Migration to Babel7 and @babel/preset-typescript (#33093) 2019-03-26 20:44:03 +00:00
README.md Functional test setup with kbn-test package (#18568) 2018-05-09 18:23:49 -05:00
tsconfig.json [ts][ftr] improve types for ftr and expect.js, cleanup changes to tsconfig files (#31948) 2019-02-28 12:06:00 -08:00

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.