Your window into the Elastic Stack
Find a file
Eyo O. Eyo 1f0f8d2c52
[React18] Migrate test suites to account for testing library upgrades obs-ux-logs-team (#201148)
This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.

##  Context

In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.

***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***

WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.

In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.

It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.

### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.

## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
2024-11-25 04:49:51 -06:00
.buildkite
.devcontainer
.github
api_docs
config
dev_docs
docs
examples
kbn_pm
legacy_rfcs
licenses
oas_docs
packages [React18] Migrate test suites to account for testing library upgrades obs-ux-logs-team (#201148) 2024-11-25 04:49:51 -06:00
plugins
scripts
src ironbank: leftover for updating ironbank to 9.5 (#201325) 2024-11-25 04:37:47 -06:00
test
typings
x-pack [React18] Migrate test suites to account for testing library upgrades obs-ux-logs-team (#201148) 2024-11-25 04:49:51 -06:00
.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

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:

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:

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.