Explore this comprehensive guide on unit testing that delves into aligning tests with user interactions, the pivotal role of clear unit tests, and optimizing component interaction testing. Learn about the significance of maintaining semantic structure for improved search engine performance and enhanced user experience. Discover practical examples and a prioritized approach for effective component element selection. The article also provides insights into utilizing over and offers valuable tips on selecting appropriate queries for robust testing. This resource is a must-read for developers aiming to elevate their unit testing practices. userEvent fireEvent General Approach In the realm of unit testing, it's crucial to align your tests with user interactions. Aim to replicate how users engage with components, focusing on factors like role, text content, and labels instead of technical details such as class or id. The Significance of Clear and Appropriate Unit Tests Unit tests serve a dual purpose: not only do they validate both existing and new functionality to ensure proper functioning, but they also encourage engineers to produce code that is semantically reliable. Maintaining semantic structure impacts search engine performance, enhances web accessibility, and contributes to an improved user experience. Components Interaction User interactions with components often involve actions like clicking, typing, and hovering. To effectively test these interactions, steer clear of using , which dispatches DOM events. Opt for instead; it simulates comprehensive interactions, triggering multiple events and performing additional checks along the way for a more thorough assessment of your components' behavior. fireEvent userEvent is a lightweight wrapper around the browser's low-level dispatchEvent API, which allows developers to trigger any event on any element. fireEvent is a wrapper around fireEvent that allows you to describe a user interaction instead of a concrete event. It adds visibility and interactability checks along the way and manipulates the DOM just like a user interaction in the browser would. It factors in that the browser e.g. wouldn't let a user click a hidden element or type in a disabled text box. userEvent Example test('types into text box', () => {
  render(<textarea />)

  // ❌ Bad approach
  fireEvent.change(screen.getByRole('textbox'), {
      target: { value: 'Hello World!' },
  })

  // ✅ Good approach
  userEvent.type(screen.getByRole('textbox'), 'Hello World!')

  expect(screen.getByRole('textbox')).toHaveValue('Hello,\nWorld!')
}) React documentation about the differences Selection of component elements Tests should look for component elements in the same way as a user would. The user cannot search the page for elements by their class, id, or test-id. But the user can search for elements by their role, by the text that the element contains, by the label. Use data-testid only in edge cases. If you cannot select the element by role, containing text, label, etc. Then it indicates to you that the component structure should be probably refactored. Using data-testid attributes do not resemble how your software is used and should be . That said, they are better than querying based on DOM structure or styling css class names. avoided if possible way Example test('types into text box', () => {
  const { container } = render(<Example />)

  // ❌ Bad approach. Don't use querySelector or other DOM methods. The user doesn't see the class name on the page.
  const button = container.querySelector('.btn-primary')

  // ❌ Bad approach. The user doesn't test-id of elements. The user doesn't see the DOM stracture and nested attributes.
  const button = screen.getByTestId('foot').firstChild

  // ✅ Good aproach. The user can find a button element.
  const button = screen.getByRole('button')

  // ✅ Good aproach. The user can find an element by text inside that.
  const button = screen.getByText('Loaded')

  expect(message).toHaveTextContext('Loaded')
}) Good explanation about test-id Priority Based on , your test should resemble how users interact with your code (component, page, etc.) as much as possible. With this in mind, we recommend this order of priority: the Guiding Principles Queries that reflect the experience of visual/mouse users as well as those that use assistive technology. Queries Accessible to Everyone : This can be used to query every element that is exposed in the . With the name option you can filter the returned elements by their . This should be your top preference for just about everything. There's not much you can't get with this (if you can't, it's possible your UI is inaccessible). Most often, this will be used with the name option like so: . Check the . getByRole accessibility tree accessible name getByRole('button', {name: /submit/i}) list of roles : This method is really good for form fields. When navigating through a website form, users find elements using label text. This method emulates that behavior, so it should be your top preference. getByLabelText : . But if that's all you have, then it's better than alternatives. getByPlaceholderText A placeholder is not a substitute for a label : Outside of forms, text content is the main way users find elements. This method can be used to find non-interactive elements (like divs, spans, and paragraphs). getByText : The current value of a form element can be useful when navigating a page with filled-in values. getByDisplayValue HTML5 and ARIA compliant selectors. Note that the user experience of interacting with these attributes varies greatly across browsers and assistive technology. Semantic Queries : If your element is one which supports alt text (img, area, input, and any custom element), then you can use this to find that element. getByAltText : The title attribute is not consistently read by screenreaders, and is not visible by default for sighted users getByTitle Test IDs : The user cannot see (or hear) these, so this is only recommended for cases where you can't match by role or text or it doesn't make sense (e.g. the text is dynamic). getByTestId Queries , which React Testing Library is built on top of, now exposes a object which has every query built-in. The changed best practice is to always use object and no longer destructure the object returned by render. The benefit of using a is you no longer need to keep the render call destructure up-to-date as you add/remove the queries you need. You only need to type screen and react testing library implementation will take care of the rest. DOM Testing Library screen screen screen Example test('renders a message', () => {
  const { getByText } = render(<Greeting />)

  // ❌ Bad approach.
  expect(getByText('Hello, world!')).toBeInTheDocument()

  // ✅ Good aproach
  expect(screen.getByText('Hello, world!')).toBeInTheDocument()
}) * vs * getBy queryBy The methods throw an error when the element is not found. So when we are asserting if an element is present (e.g. )) and it’s not found, using the methods will offer a better error message over or . Similarly, the methods return null instead of throwing, which is perfect when testing when an element is not present. That way the test will fail on the assertion ( ) instead of throwing an error with the methods. get* .toBeInTheDocument( get* query* find* query* .not.ToBeInTheDocument() get* Example test('renders a message', () => {
  render(<Greeting />)

  // ✅ use get* when asserting presence
  expect(screen.getByText('Hello, world!')).toBeInTheDocument()

  // ✅ use query* when asserting absence
  expect(screen.queryByRole('region')).not.toBeInTheDocument()
}) findBy* The returns a Promise which resolves when an element is found which matches the given query. The promise is rejected if no element is found or if more than one element is found after a default timeout of 1000ms. So, use when you expect that the element will appear after some async changes. findBy* Async calls findBy* Use when handling the element that is not available right away, as  findBy* throws better error message. findBy* // ❌
const submitButton = await waitFor(() =>
  screen.getByRole('button', {name: /submit/i}),
)

// ✅
const submitButton = await screen.findByRole('button', {name: /submit/i}) waitFor Do not use side effects in block waitFor is intended for things that have a non-deterministic amount of time between the action you performed and the assertion passing. Because of this, the callback can be called (or checked for errors) a non-deterministic number of times and frequency (it's called both on an interval as well as when there are DOM mutations). So this means that your side-effect could run multiple times! WaitFor // ❌
await waitFor(() => {
  fireEvent.keyDown(input, {key: 'ArrowDown'})
  expect(screen.getAllByRole('listitem')).toHaveLength(3)
})

// ✅
userEvent.keyboard('[ArrowDown]')
await waitFor(() => {
  expect(screen.getAllByRole('listitem')).toHaveLength(3)
}) Checking visibility via CSS styles toBeVisible test('renders a hidden message', () => {
  const { getByText } = render(
      <div style="display: none">
        Hello, world!
      </div>
);

  // ❌ Bad approach.
  expect(getByText('Hello, world!')).toHaveStyle('display: none');

  // ✅ Good aproach
  expect(screen.getByText('Hello, world!')).not.toBeVisible();
}) ⚠️ For child component’s toBeVisible will not work. This is a known issue: ACHTUNG: https://github.com/testing-library/jest-dom/issues/209 https://github.com/testing-library/jest-dom/pull/428 test('renders a message', () => {
  render(
        <div style="display: none">
          <button>Hello, world!</button>
        </div>)

  // ❌ Wont work.
  expect(screen.getByText('Hello, world!')).not.toBeVisible();
}) Useful links https://chrome.google.com/webstore/detail/testing-library-which-que/olmmagdolfehlpjmbkmondggbebeimoh - the extension that helps to choose the appropriate selector for the element https://chrome.google.com/webstore/detail/testing-library-which-que/olmmagdolfehlpjmbkmondggbebeimoh - the extension that helps to choose the appropriate selector for the element https://chrome.google.com/webstore/detail/testing-playground/hejbmebodbijjdhflfknehhcgaklhano - the extension that allows user to write live unit tests (on the page) https://kentcdodds.com/blog/common-mistakes-with-react-testing-library#having-multiple-assertions-in-a-single-waitfor-callback Also published here.

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Elevate Your Code Quality with Effective Unit Testing

Too Long; Didn't Read

Andrey Denisov

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Elevate Your Code Quality with Effective Unit Testing

Too Long; Didn't Read

Andrey Denisov

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES