mirror of
https://github.com/elastic/kibana.git
synced 2025-04-24 17:59:23 -04:00
Your window into the Elastic Stack
bd13e82949
## Summary `@kbn/scout-oblt` is a test library that extends `@kbn/scout` with test helpers specifically designed to test `Observability` applications in Kibana. All Oblt plugins should only import from `@kbn/scout-oblt` Its primary goal is to simplify the test development experience for teams working on `Observability` plugins by providing custom Playwright fixtures, page objects, and utilities tailored for Observability-related testing scenarios. Contributing: - when Fixture/Page Object is sharable across all Solutions and Platform (`fleetApi` fixture), it should be added in `@kbn/scout` - when Fixture/Page Object is Oblt-specific but is shared across tests under the multiple plugins (`OnboardingHome` page), it should be added in `@kbn/scout-oblt` - when Fixture/Page Object is only used in a single plugin (`onboarding` internal APIs ?), it should be added in this plugin. I also re-worked existing tests with few ideas in mind: - Scout is **e2e testing tool** and should target primary e2e test scenarios; We have _API integration tests_ to test multiple short scenarios for APIs behavior (response, status code) and _jest/React testing library_ to test components in isolation (elements rendering, fields validation). Doing all the testing with e2e tool like Playwright will dramatically affect cost efficiency and stability of tests, but also slows overall CI execution and PRs delivery. The goal is to follow testing pyramid and keep in mind its principles. - We on purpose spin up new browser context for each `test` block to make sure our **tests are independent**. Having too many short `test` blocks in the file significantly slows down the execution: every block triggers browser context, saml authentication, adding/removing Fleet integrations (each call up to 2 seconds) and other beforeEach/afterEach hooks. Real browser-based testing is expensive. It is not about putting every step into 1 `test` block, but also not a Jest unit-test-style design. When it is possible to group similar actions on the same page and if it is a part of the same user flow - we should do it. It also doesn't bring the testing value repeating the same UI steps multiple times in different scenarios. _Our CI costs are critical to cut when it is possible_ - Avoid **nesting describe** blocks: it complicates test readability and also complicates for CI bot to properly skip the failing block (it will skip the top level one). We encourage **Scout parallel test execution** based on running test spec files in multiple workers, not the `test` blocks within the same file. Having too many `test` blocks in the same file will be slowly run in the single thread and in case of flakiness, it means Team lose more test coverage than they probably expect. Before (**59** test blocks - **8-8.5 min** per distro): <img width="1709" alt="Screenshot 2025-02-08 at 18 01 40" src="https://github.com/user-attachments/assets/5fd65a1c-85f9-4594-9dae-3f8e99a005ab" /> After (**15** test blocks - **3.5-4 min** per distro): <img width="1578" alt="Screenshot 2025-02-10 at 18 14 42" src="https://github.com/user-attachments/assets/6846898f-7dd2-4f6b-8bc5-d06741b0b120" /> For reviewers: updated tests are possible to run in 2 parallel workers against the same Kibana/ES instance and run time is dropping to **2.5-3 min** 🚀 . It is up to UX-Logs team to decide if you want to keep parallel run (new tests can be added either to parallel or sequential run) <img width="1578" alt="Screenshot 2025-02-11 at 12 14 30" src="https://github.com/user-attachments/assets/e94113f2-d7f1-470e-a6d5-cb5154d99c41" /> --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> |
||
|---|---|---|
| .buildkite | ||
| .devcontainer | ||
| .github | ||
| api_docs | ||
| config | ||
| dev_docs | ||
| docs | ||
| examples | ||
| kbn_pm | ||
| legacy_rfcs | ||
| licenses | ||
| oas_docs | ||
| packages | ||
| plugins | ||
| scripts | ||
| src | ||
| test | ||
| typings | ||
| x-pack | ||
| .backportrc.json | ||
| .bazelignore | ||
| .bazeliskversion | ||
| .bazelrc | ||
| .bazelrc.common | ||
| .bazelversion | ||
| .browserslistrc | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .i18nrc.json | ||
| .node-version | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| .puppeteerrc | ||
| .stylelintignore | ||
| .stylelintrc | ||
| .telemetryrc.json | ||
| .yarnrc | ||
| BUILD.bazel | ||
| catalog-info.yaml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| FAQ.md | ||
| fleet_packages.json | ||
| github_checks_reporter.json | ||
| kibana.d.ts | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| package.json | ||
| preinstall_check.js | ||
| README.md | ||
| renovate.json | ||
| RISK_MATRIX.mdx | ||
| run_fleet_setup_parallel.sh | ||
| SECURITY.md | ||
| sonar-project.properties | ||
| STYLEGUIDE.mdx | ||
| tsconfig.base.json | ||
| tsconfig.browser.json | ||
| tsconfig.browser_bazel.json | ||
| tsconfig.json | ||
| TYPESCRIPT.md | ||
| updatecli-compose.yaml | ||
| versions.json | ||
| WORKSPACE.bazel | ||
| yarn.lock | ||
Kibana
Kibana is your window into the Elastic Stack. Specifically, it's a browser-based analytics and search dashboard for Elasticsearch.
- Getting Started
- Documentation
- Version Compatibility with Elasticsearch
- Questions? Problems? Suggestions?
Getting Started
If you just want to try Kibana out, check out the Elastic Stack Getting Started Page to give it a whirl.
If you're interested in diving a bit deeper and getting a taste of Kibana's capabilities, head over to the Kibana Getting Started Page.
Using a Kibana Release
If you want to use a Kibana release in production, give it a test run, or just play around:
- Download the latest version on the Kibana Download Page.
- Learn more about Kibana's features and capabilities on the Kibana Product Page.
- We also offer a hosted version of Kibana on our Cloud Service.
Building and Running Kibana, and/or Contributing Code
You might want to build Kibana locally to contribute some code, test out the latest features, or try out an open PR:
- CONTRIBUTING.md will help you get Kibana up and running.
- If you would like to contribute code, please follow our STYLEGUIDE.mdx.
- For all other questions, check out the FAQ.md and wiki.
Documentation
Visit Elastic.co for the full Kibana documentation.
For information about building the documentation, see the README in elastic/docs.
Version Compatibility with Elasticsearch
Ideally, you should be running Elasticsearch and Kibana with matching version numbers. If your Elasticsearch has an older version number or a newer major number than Kibana, then Kibana will fail to run. If Elasticsearch has a newer minor or patch number than Kibana, then the Kibana Server will log a warning.
Note: The version numbers below are only examples, meant to illustrate the relationships between different types of version numbers.
| Situation | Example Kibana version | Example ES version | Outcome |
|---|---|---|---|
| Versions are the same. | 7.15.1 | 7.15.1 | 💚 OK |
| ES patch number is newer. | 7.15.0 | 7.15.1 | ⚠️ Logged warning |
| ES minor number is newer. | 7.14.2 | 7.15.0 | ⚠️ Logged warning |
| ES major number is newer. | 7.15.1 | 8.0.0 | 🚫 Fatal error |
| ES patch number is older. | 7.15.1 | 7.15.0 | ⚠️ Logged warning |
| ES minor number is older. | 7.15.1 | 7.14.2 | 🚫 Fatal error |
| ES major number is older. | 8.0.0 | 7.15.1 | 🚫 Fatal error |
Questions? Problems? Suggestions?
- If you've found a bug or want to request a feature, please create a GitHub Issue. Please check to make sure someone else hasn't already created an issue for the same topic.
- Need help using Kibana? Ask away on our Kibana Discuss Forum and a fellow community member or Elastic engineer will be glad to help you out.