kibana

mirror of https://github.com/elastic/kibana.git synced 2025-06-27 18:51:07 -04:00

History

Anton Dosov 24d4c8aa0b [Concurrent React@18] Switch testing library to `createRoot` (#213367 ) Closes https://github.com/elastic/kibana/issues/218076. Part of the preparation for migrating Kibana to React’s createRoot ([Epic](https://github.com/elastic/kibana-team/issues/1564)). ## What’s in this PR - Switch to `createRoot` in tests: Updates `@testing-library/react` to use `createRoot` by default. All unit tests using Testing Library now run in concurrent mode. See commit: `8e51e07054` - Test updates: Most test failures from the switch have been addressed. About a dozen tests still explicitly set `legacyRoot: true`. These will need closer review by the owning teams during app migrations. - Enzyme tests: Enzyme tests continue to use the React 17 adapter and run in legacy mode. [Current plan](https://docs.google.com/document/d/1CXybQiBAtXt3Kay0j_CJxWO7bZ2EYYhaveK4fban2-M/edit?tab=t.kfgvma8ti7q0) is to migrate away from Enzyme before upgrading to React 19. ## Background When we upgraded to React 18, we also updated `@testing-library/react`, which by default uses `createRoot`. To avoid dealing with concurrent mode failures early, we temporarily forced Testing Library to use `legacyRoot` (`ReactDOM.render`). This PR removes that override and fixes the resulting test issues, completing the move to concurrent root for Testing Library tests. ### Common Failures #### 🔴 `el.click()` A common testing mistake is using el.click() and immediately checking for a DOM update: ``` el.click(); expect(el).toHaveAttribute('state-updated'); ``` This often fails with Concurrent React, because state updates might not be synchronous anymore. Directly calling `el.click()` doesn't automatically trigger React’s update cycle (`act`), so your test can read outdated DOM. Instead, you should either manually wrap the interaction in `act`, or (better) use `userEvent.click`, which already uses `act` internally and simulates real user behavior more accurately: ```diff - el.click(); + await userEvent.click(el); expect(el).toHaveAttribute('state-updated'); ``` #### 🔴 Wrapping `render` call inside `act` `act(() => render(<App/>))` Another common mistake is wrapping the render call inside act: ``` await act(async () => { render(<MyComponent />); }); ``` This is sometimes done to "mute" warnings about Promises resolving inside `useEffect`. However, wrapping `render` in `act` manually breaks a lot of tests in Concurrent React, because the library (like React Testing Library) already wraps render in act internally. Manually adding act here can cause unexpected behavior, like missing updates or wrong timing. The approach I took was to remove the manual `act` around `render` in places where tests started failing with Concurrent React, even if, in some cases, it means seeing `act` warnings in the console. This is safer for correctness and allows the tests to pass reliably. To properly mute such warnings, the right way would be to wrap the actual resolved Promises (like those inside useEffect) in act.However, since doing that depends a lot on the specific test setup, and could vary case-by-case, I chose not to try to fix it myself. Teams are welcome to follow up if they wish. ### 🟡 In specific tests we keep `legacyMode: true` When it wasn't immediately clear to me what caused the failure or when the tests were checking React internals, like the number of re-renders, I decided to keep that test running in legacy mode by using the option `legacyRoot: true` in `render`. The idea behind these in-place overrides is that when we're ready to start migrating the runtime to concurrent mode, the owning teams will need to take a closer look at those tests when moving their apps to the concurrent root.		2025-05-08 13:59:44 +02:00
..
jest_integration	[scout] Add Jest events reporter (#214662 )	2025-04-03 19:20:33 +01:00
jest_integration_node	[scout] Add Jest events reporter (#214662 )	2025-04-03 19:20:33 +01:00
jest_node
src	[Concurrent React@18] Switch testing library to `createRoot` (#213367 )	2025-05-08 13:59:44 +02:00
types/ftr_globals
index.ts
jest-preset.js	Update rbush to v4 (main) (manual) (#219613 )	2025-04-30 09:03:13 -04:00
jest.config.js
jest.integration.config.js
kbn_test_config.ts
kibana.jsonc
package.json
README.mdx	SKA: Relocate /test to /src/platform/test (#210956 )	2025-03-14 16:57:23 +00:00
tsconfig.json	[jest] @emotion/babel-preset-css-prop (#216489 )	2025-04-14 14:29:47 +02:00

README.mdx

---
id: kibDevDocsOpsTest
slug: /kibana-dev-docs/ops/test
title: '@kbn/test'
description: A package provide ways to run tests
date: 2022-08-15
tags: ['kibana', 'dev', 'contributor', 'operations', 'cli', 'dev', 'mode', 'test']
---

# 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`](../../../../../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`](../../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<string>)`

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](../../../../../src/platform/test/functional/config.base.js), following the config schema specified [here](../../../../../src/functional_test_runner/lib/config/schema.js).

Internally the method that starts Elasticsearch comes from [kbn-es](../../../../../src/platform/packages/shared/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](../../../../../src/platform/test/functional/config.base.js), following the config schema specified [here](../../../../../src/functional_test_runner/lib/config/schema.js).

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](../../../../../scripts/README.md)).

## 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](../../../../../src/platform/packages/shared/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.