vitest-browser-react

Render React components in Vitest Browser Mode. This library follows testing-library principles and exposes only locators and utilities that encourage you to write tests that closely resemble how your React components are used.

vitest-browser-react aims to deliver a good developer experience in Vitest Browser Mode by incorporating the locators API and retry-ability mechanism directly into the render result. This allows you to call user methods without needing to verify the element's existence or wait for external events (like API calls) to render the element.

Requires vitest and @vitest/browser 2.1.0 or higher.

1import { render } from 'vitest-browser-react'
2import { expect, test } from 'vitest'
3
4test('counter button increments the count', async () => {
5  const screen = render(<Component count={1} />)
6
7  await screen.getByRole('button', { name: 'Increment' }).click()
8
9  await expect.element(screen.getByText('Count is 2')).toBeVisible()
10})

💡 This library doesn't expose React's act and uses it only to flush operations happening as part of useEffect during initial rendering and unmounting. Other use cases are handled by CDP and expect.element which both have built-in retry-ability mechanism.

vitest-browser-react also exposes renderHook helper to test React hooks.

1import { renderHook } from 'vitest-browser-react'
2import { expect, test } from 'vitest'
3
4test('should increment counter', async () => {
5  const { result, act } = renderHook(() => useCounter())
6
7  act(() => {
8    result.current.increment()
9  })
10
11  expect(result.current.count).toBe(1)
12})

vitest-browser-react also automatically injects render method on the page. Example:

1// vitest.config.ts
2import { defineConfig } from 'vitest/config'
3
4export default defineConfig({
5  test: {
6    setupFiles: ['./setup-file.ts'],
7    browser: {
8      name: 'chromium',
9      enabled: true,
10    },
11  },
12})
13
14// ./setup-file.ts
15// add an import at the top of your setup file so TypeScript can pick up types
16import 'vitest-browser-react'

1import { page } from '@vitest/browser/context'
2
3test('counter button increments the count', async () => {
4  const screen = page.render(<Component count={1} />)
5
6  screen.cleanup()
7})

Unlike @testing-library/react, vitest-browser-react performs cleanup of the component before the test begins, allowing you to see the rendered result in the Browser UI. If you prefer to disable auto-cleanup, you can import the render function from vitest-browser-react/pure.

Configuration

You can configure if the component should be rendered in Strict Mode with configure method from vitest-browser-react/pure:

1import { configure } from 'vitest-browser-react/pure'
2
3configure({
4  // disabled by default
5  reactStrictMode: true,
6})

The difference with @testing-library/react

The main difference is that vitest-browser-react integrates with Vitest Browser Mode locators: https://github.com/vitest-dev/vitest/discussions/5828#discussioncomment-10314822

Locators are nice because they provide an intuitive and ergonomic way to query and make assertions:

1await expect.element(page.getByRole('button')).toBeVisible()

You can write the same with testing-library:

1const button = await screen.findByRole('button')
2expect(button).toBeVisible()
3
4// or
5await expect.poll(() => screen.getByRole('button')).toBeVisible()

One nice thing that comes out of this approach is that Vitest can keep querying the element during the assertion instead of before. This means that if the element was found, but it has an invalid state, the assertion will continue checking the element until it works. This makes your tests less flaky.

1const button = await screen.findByRole('button')
2// it's possible that the element is in the dom, but its state is invalid
3// but it will be valid in a few render cycles
4expect(button).toBeVisible()
5
6// even if element is in the dom, it might not be visible yet
7// vitest will continue checking the validity
8await expect.element(page.getByRole('button')).toBeVisible()

Another example is with user-event. Vitest provides a similar API to testing-library, but uses CDP instead of faking events which is closer to how browsers work:

1await page.getByRole('button').click()
2// or
3await userEvent.click(page.getByRole('button'))

You can write the same with testing-library:

1const button = await screen.findByRole('button')
2await userEvent.click(button)

In short, this library integrates well with Vitest Browser Locators API, and that is why it's recommended for the Browser Mode, although you can continue using testing-library if you prefer.

One of the reasons why the Vitest team decided to add our own wrapper was because it became confusing to document all the differences with how testing-library works in Vitest: the dom/render libraries work the same, but user-event is not (except sometimes, such as with the preview provider). Streamlining the API made it easier to explain and more approachable for newcomers.

Special thanks

• Inspired by @testing-library/react