89f9260da2
* initial implementation of configurable test users * user superuser by default to match master * referenced the configs in reporting and api integration * setting the minimum number of default roles * looking for x-pack tests with users and roles * add testUserService in dashboard mode tests * running only ciGroup7 * uncommenting - addign visualization * re-enabling all CI groups to run on CI * reinstating Jenkinsfile * disable Test user for OIDC config * improved logging and added Roles for OSS tests to get better info on the runs. * disable test_user for auth tests * don't fetch enabledPlugins when testuser disabled * fix es-lint * running oss tests with x-pack enabled * [revertme] build default dist for oss tests * updating NOTICE.txt file as it complained in the kibana intake tests * changed to pick OSS builds * trying a license change to trial * switch back to xpack builds * created a new sample data role and used it in homepage tests * revert test/scripts/jenkins_ci_group.sh * only refresh browser and wait for chrome if we are already on Kibana page * fix large_string test to use minimum set of roles and privileges * fix for date nanos custom timestamp with a configured role * changes to the files with addition of new roles for the test_user * reverting to OSS changes and few additions to the time_zone test to run as a test_user * changes to security * changes to the x-pack test to use elastic superuser * fix for chart_types test * fixes to area chart , input control test * fix for dashboard filtering test and a new config role * changes to handle the x-pack tests * additional role for date nanos mixed * added the logstash role to the accessibility tests * removed telemetry setting * docs+few changes to the tests * removed Page navigation * removed pageNavigation which was unused * test/accessibility/apps/management.ts * update management.ts * aria label, and other changes * accidentally checked in a piped file with results. * accidentally checked in a piped file with results. * accidentally checked in a piped file with results. * accidentally checked in a piped file with results. * accidentally checked in a piped file with results. * accidentally checked in a piped file with results. * accidentally checked in a piped file with results. * accidentally checked in a piped file with results. * reverted * unloading of logstash data, fixing aria label * aria-label * added the required role * fix for tsvb chart * fix for sample data test reverted home_page pageobject file * changes to sample data test and visualize index file to incorporate OSS changes * changes to describe() and some more changes to incorporate in settings_page * re-adding the after() * removed unwanted roles * replaced kibana_user with kibana_admin * added the check of deprecated kibana_user * testing with kibana_admin role * fix for discover test * incorporated the review comments * incorporated the review comments * incorporate review comments and added restoreDefaults() * removed describe.only * reverted the OSS logic change I had here- pulled into seperate PR * incorporated the review comments * incorporated review changes * adding hidden=true to find hidden kibanaChrome * change field.test.tsx to be same as that of master branch Co-authored-by: spalger <spalger@users.noreply.github.com> 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.