Testing Library. Асинхронщина. findBy

Мы помним, что у нас есть три вида запросов - getBy, queryBy и findBy. Так вот findBy - это комбинация getBy и уже рассмотренного выше метода waitFor. Таким образом, запрос findBy по умолчанию ожидает, когда искомый элемент появится на странице.

Можно использовать в комбинации с await:

await screen.findByText('Clicked once')

#тестирование #testinglibrary #документация #примерыкода

Testing Library. Асинхронщина. waitForElementToBeRemoved

Есть еще одна утилита, позволяющая дождаться, когда конкретный элемент исчезнет со страницы: waitForElementToBeRemoved.

Первым параметром она принимает элемент или массив элементов. Кроме того, можно передать функцию-коллбэк, которая вернет элемент или массив элементов. Если элемент null или массив пустой, будет ошибка.

const el = document.querySelector('div.getOuttaHere')
await waitForElementToBeRemoved(el)

Вторым параметром можно передать объект с настройками, такой же как у функции waitFor.

#тестирование #testinglibrary #документация #примерыкода

Testing Library. Размышления о fireEvent

Хорошая статья в документации про особенности эмуляции событий: https://testing-library.com/docs/guide-events

Помня о главном принципе библиотеки, что "тестировать нужно максимально похоже на то, как действует реальный пользователь", мы тем не менее должны помнить о некоторых условностях, особенно в работе с событиями.

Например, если мы вызываем метод fireEvent.click(element), он задиспатчит событие клика и сработает обработчик клика, если он есть. В большинстве случаев нам этого более чем достаточно. Однако когда настоящий юзер кликает на настоящий элемент, мы получаем гораздо больше событий: mouseOver, mouseMove, mouseDown, focus (если элемент focusable), mouseUp и только теперь, наконец, click.

Про это важно помнить, чтобы не столкнуться однажды с неожиданным и непонятным поведением.

Статья предлагает пару паттернов для эмуляции событий с помощью fireEvent. Например, вместо прямого вызова события keyDown на элементе, лучше сначала сфокусироваться на нем, а затем вызвать событие на document.activeElement:

getByText('click me')
fireEvent.keyDown(document.activeElement || document.body)

#тестирование #testinglibrary #документация #примерыкода

Testing Library. Тестирование доступности

Если возникла необходимость затестить доступность вашего приложения, Testing Library предлагает пару полезных утилит:

getRoles

Находит на странице все элементы, имеющие роли, и возвращает их в виде объекта

logRoles

То же самое, только выводит данные в консоль.

isInaccessible

Проверяет, исключен ли элемент из дерева доступности браузера.

Подробнее в документации: https://testing-library.com/docs/dom-testing-library/api-accessibility

#тестирование #testinglibrary #документация

Testing Library. Debugging

Библиотека предоставляет ряд возможностей для отладки

- Если запросы get или find не находят элементов, то они выбрасывают ошибку, а в консоль выводится DOM корневого элемента (screen или container)
- Утилита prettyDOM принимает элемент и возвращает его структуру
- Метод screen.debug() или screen.debug(element) также получает DOM элемента и выводит его в консоль
- Метод screen.logTestingPlaygroundURL() выводит урл песочницы, в которой уже будет сохранен ваш документ
- Утилита logRoles выводит все элементы, имеющие роли

Подробнее в документации: https://testing-library.com/docs/dom-testing-library/api-debugging

#тестирование #testinglibrary #документация

Testing Library. within и кастомные запросы

Библиотека также предоставляет ряд низкоуровневых функций для построения более точных/сложных запросов: https://testing-library.com/docs/dom-testing-library/api-custom-queries

И еще есть полезная функция within(element). Она оборачивает полученный элемент и возвращает объект со всеми уже известными нам методами (как у объекта screen). И все эти методы работают "в контексте" полученного элемента: https://testing-library.com/docs/dom-testing-library/api-within

#тестирование #testinglibrary #документация

Валидация форм с react-hook-form в React-приложениях

Видео (рус.): https://youtu.be/Jxfun6Jnt5Q

Быстрое и понятное введение в работу с библиотекой react-hook-form. Достаточно подробно описано, как настроить валидацию для формы с неконтролируемыми полями.

#видео #react #forms

user-event

user-event - это библиотека для симуляции пользовательских событий, которую мы можем использовать вместо fireEvent. Можно импортировать из пакета @testing-library/user-event.

В чем разница между user-event и fireEvent?
fireEvent просто диспатчит события DOM, это лишь удобная обертка над методом dispatchEvent.
А user-event пытается имитировать полноценное взаимодействие, которое обычно состоит из нескольких событий.

Простой пример - изменение значения поля ввода.
fireEvent просто задиспатчит событие ‘change’ с нужной строкой, хотя в реальной жизни поле сначала получит фокус, а затем будет ряд событий клавиатуры. user-event пытается все это имитировать, а заодно делает кучу проверок: например, не получится ввести текст в заблокированный инпут.

Настоящий пользователь в браузере вызывает trusted-события, которые нельзя создать программно, а user-event подменяет UI-слой, с которым взаимодействует пользователь в браузере, чтобы это имитировать.

Настройка

Прежде чем использовать методы из этой библиотеки в наших тестах, ее нужно настроить с помощью метода setup. Документация рекомендует делать это до того, как вы отрендерили DOM:

const user = userEvent.setup() // инициализация
render(…)
 await user.click(screen.getByRole('button', {name: /click me!/i}))

В метод можно передать ряд настроек: https://testing-library.com/docs/user-event/options

В результате мы получаем объект user с кучей полезных методов для создания интерактивности.

Доступные API и методы

👉 type

Для ввода значения в поле ввода.
Первым аргументом принимает само поле, вторым - текст, третим - объект с настройками.

user.type(input, ' World!')

👉 clear

Очистка editable-элемента (фокус, выделение контента, удаление)

user.clear(screen.getByRole('textbox'))

👉 selectOptions/deselectOptions

Работа с селектами или listbox.

user.selectOptions(screen.getByRole('listbox'), ['1', 'C'])

👉 upload

Для загрузки файлов через input[type=«file»]

user.upload(input, new File(['hello'], 'hello.png', {type: 'image/png'}))

👉 clipboard: copy, cut, paste

Работа с буфером обмена. Библиотека подменяет реальный window.navigator.clipboard собственным стабом.
Дока: https://testing-library.com/docs/user-event/clipboard

👉 keyboard

Для симуляции событий клавиатуры, ввода текста. Символы можно указать просто текстом, а также по значениею KeyboardEvent.key или KeyboardEvent.code
Дока: https://testing-library.com/docs/user-event/keyboard

У этого метода также есть шорткат tab (https://testing-library.com/docs/user-event/convenience)


👉 pointer

Работа указателем. Некоторые возможности этого метода не очень актуальны, если вы работаете с jsdom, так как в этом случае реальная отрисовка страницы не происходит.
Дока: https://testing-library.com/docs/user-event/pointer

Это сложный метод, у которого есть много шорткатов (подробнее тут https://testing-library.com/docs/user-event/convenience):

⁃ click
⁃ dblClick
⁃ tripleClick
⁃ hover
⁃ unhover

#тестирование #testinglibrary #документация

​React Testing Library. Первая проба

Наконец-то то, ради чего мы тут и собрались в общем-то. Как использовать Testing Library в React-проектах?

Очень просто, они нам предоставляют обертку @testing-library/react, которая реализует методы для удобной работы с компонентами React.

👀 Тестируем компонент Button вживую: https://codesandbox.io/p/devbox/react-testing-library-react-junior-2yqhll

Сложнее всего тут - настроить окружение, а сами тесты пишутся очень просто и логично.

Итак, нам понадобится:

👉 @testing-library/react - это обертка над @testing-library/dom, поэтому dom нам не нужен.
👉 @testing-library/jest-dom - для добавления полезных утверждений
👉 @testing-library/user-event - для эмуляции пользовательских событий
👉 а также компонент, который нужно протестировать - Button

Тесты в примере очень простые, чтобы разобраться, как это дело заводится.

Первым тестом мы проверяем, что наш компонент в принципе рендерится. Для этого используем метод render из @testing-library/react. Он возвращает объект с уже знакомыми нам методами типа getByRole, findByText и так далее. Соответственно все они работают именно с тем фрагментом, который мы отрендерили.
Находим нашу кнопку по ее тексту (можно и по роли). И утверждаем, что она есть в документе (`expect(button).toBeInTheDocument`).

Второй тест чуть сложнее, он проверяет, что при клике на кнопку вызывает функция-обработчик. Для этого мы создаем поддельную функцию (`jest.fn()`) и передаем ее в компонент в пропе onClick. Опять рендерим, находим кнопку и кликаем на нее, используя метод click из библиотеки user-event (хотя тут можно и нативным кликом обойтись). Наконец, утверждаем, что наша мокнутая функция-обработчик была вызвана (`expect(onClick).toHaveBeenCalled()`).

Все логично, методы удобные, ничего больше не мешает писать тесты))

#тестирование #testinglibrary #документация #примерыкода

​React Testing Library. Пример с сетевыми запросами

Еще один пример тестирования с использованием React Testing Library: https://codesandbox.io/p/sandbox/react-testing-library-fetch-react-junior-vc465v

У нас есть компонент с кнопкой, при клике на которую из публичного api загружается и отображается картинка, то есть уходит сетевой запрос.

Нам нужно это протестировать: что при клике загружается и отображается картинка.

Алгоритм такой:

⁃ рендерим компонент
⁃ находим кнопку
⁃ кликаем
⁃ ждем, когда на странице появится картинка
⁃ проверяем ее адрес

Но для этого нам нужно перехватить и подменить запрос. Для этого существуют специальные утилиты, типа msw или nock. Они очень простые и отлично работают. Однако у меня не получилось завести их на демонстрационной площадке, поэтому пришлось использовать корявую подмену метода fetch.

В тесте стоит обратить внимание на две вещи:

👉 мы ждем, когда изображение появится на странице, используя await и find-запрос, который возвращает промис
👉 для утверждения используем метод toHaveAttribute, добавленный библиотекой @testing-library/jest-dom

#тестирование #testinglibrary #документация #примерыкода

​React Testing Library. Кастомный рендер

Мы можем настроить функцию render, передав вторым аргументом объект конфигурации. Например, можно добавить какую-то общую обертку с провайдерми для наших рендеров - параметр wrapper.

#тестирование #testinglibrary #документация #примерыкода

Render Hook

Помимо render у нас есть еще один метод - renderHook. Как можно догадаться, он предназначен для работы с хуками.

import {renderHook} from '@testing-library/react'

test('returns logged in user', () => {
  const {result, rerender} = renderHook((props = {}) => props, {
    initialProps: {name: 'Alice'},
  })
  expect(result.current).toEqual({name: 'Alice'})
  rerender()
  expect(result.current).toEqual({name: undefined})
})

Метод принимает два аргумента:
- рендер-функцию, которая должна вызвать хук и вернуть результат его работы
- объект конфигурации (опционально)

Результат работы хукуа будет доступен в поле result.current.

#тестирование #testinglibrary #документация #примерыкода

Руководство по React Testing Library

Статья (англ.): https://www.robinwieruch.de/react-testing-library/

Robin Wieruch по полочкам разложил, что такое RTL и как ей пользоваться.

1. RTL сама по себе не предназначена для организации тестов, поэтому нам в любом случае понадобится один тест-раннеров - Jest или Vitest. С их помощью напишем обертки тестов, а для конкретных действий уже будем использовать RTL.

2. В начале теста рендерим необходимые React-компоненты и сразу же перестаем о них думать как о React-компонентах. Мы должны тестировать обычный DOM, который видит пользователь.

3. RTL предоставляет огромное количество методов для поиска нужных элементов в отрендеренном фрагменте. Все они довольно подробно разобраны, кроме того, описано, когда и что предпочтительно использовать.

Запросы в testing-library

4. Пакет @testing-library/jest-dom добавляет множество удобных утверждений, вроде toBeInTheDocument.

5. Пользовательские события можно эмулировать с помощью fireEvent и user-event.

fireEvent
user-event

6. Разбираемся, как тестировать обработчики событий с помощью мокнутых функций.

7. И наконец учимся работать с асинхронными изменениями, например, сетевыми запросами, с помощью find-методов и waitFor. Не забываем мокать собственно методы, отправляющие запрос (axios/fetch/etc)

waitFor
пример тестирования компонента, выполняющего сетевой запрос


#ссылки #тестирование #testinglibrary

Testing Library. Полезные ресурсы

- документация Testing Library
- все существующие ARIA-роли для метода getByRole
- список утверждений, которые добавляются библиотекой @testing-library/jest-dom

#ссылки #тестирование #testinglibrary

Простое руководство по тестированию взаимодействия с пользователем с помощью библиотеки тестирования React

Статья (рус.): https://reddeveloper.ru/blog/363/prostoye-rukovodstvo-po-testirovaniyu-vzaimodeistviya-s-pol-zovatelem-s-pomoshch-yu-biblioteki-testirovaniya-react

Из этой статьи мы возьмем несколько примеров того, что в принципе можно тестировать, так как у меня по-прежнему есть сомнения и вопросы в этой области.

1. Поле ввода работают правильно

Имеем селект. Тестируем, что он работает правильно и выбранное пользователем значение действительно выбирается.

Полезные методы:
- getByRole('combobox')
- userEvent.selectOptiions
- expect(select).toHaveValue

2. При вводе/выборе значения оно корректно отображается в интерфейсе

Имеем селект города. Выводим выбранный город где-то в интерфейсе Тестируем, что при выборе города в селекте он изменяется и в интерфейсе.

Полезные методы:
- поиск элемента по тексту getByText
- поиск элемента другими методами, но с уточнением его текста (в настройках метода), например, getByRole('heading', { name: /moscow/i })

3. При ховере появляется элемент

Имеем тултип, который должен появляться при наведении на элемент. Тестируем, что он появляется.

Полезные методы:
- userEvent.hover
- expect(tooltip).toBeInTheDocument

4. Загрузка файлов

Проверяем, что загрузчик файлов видит загруженные файлы.

Полезные методы:
- new File(['hello'], 'hello.png', {type: 'image/png'})
- userEvent.upload(filePicker, file)
- expect(filePicker.files[0]).toEqual(file)

5. Отправка формы

Имеем форму. Тестируем, что при правильном заполнении полей форма успешно отправляется.

Также тестируем все варианты валидации:
- пустые поля
- некорректно заполненные поля

Полезные методы:
- userEvent.type(field, text)
- userEvent.selectOptions(select, option)
- userEvent.click(element)
- getByPlaceholderText(text)
- getByLabelText(text)

#ссылки #тестирование #testinglibrary

Разбираемся в React Concurrency

Статья (англ.): https://www.bbss.dev/posts/react-concurrency/

Конкурентный режим в React - фича уже не новая, но наверно еще не очень широко используемая. В статье дается хороший разбор.

Основная идея в том, что React научился прерывать рендеринг. Если у нас рендериттся что-то большое и тяжелое, пользователь не может взаимодействовать со страницей. Конкурентный режим как раз должен решать эту проблему.

Как именно эта фича реализована под капотом, в статье подробно не рассказывается. Упомянуто только, что в этом задействован пакет scheduler, а также, что используется requestAnimationFrame.

В общем, "конкурентного режима" как такового у нас нет, потому что его введение многое поломает. Вместо этого нам дали несколько "конкурентных фич", которые дают возможность избирательно запустить конкуррентный рендеринг.

useTransition

Хук useTransition возвращает метод startTransition. Он запускает transition, внутри которого все изменения будут считаться прерываемыми.

Если мы изменим стейт компонента внутри такого transition, изменения начнут применяться, но могут быть прерваны, если найдется более важное дело - например, действия пользователя.

Очевидно, что этот хук нам нужен только если мы контролируем изменения (сами их запускаем). Но как быть, если у нас нет возможности обернуть изменения в transition? Например, если мы получаем некоторое изменяющееся значение через проп.

useDeferredValue

Для этого случая есть хук useDeferredValue, который оборачивает это изменяющееся значение, но об изменениях сообщает нам только тогда, когда это ничему не мешает.

***

Таким образом, новые фичи позволяют нам явно помечать изменения как "неблокирующие". Также они работают с Suspense-компонентами.

#ссылки #concurrentmode

7 бесплатных шаблонов React для разработки проектов

Статья (рус.): https://nuancesprog.ru/p/15488/

Полноценные заготовки для проектов - чтобы не начинать работу с нуля. Есть шаблоны для лендингов, портфолио, блога, админ-панели...

#ссылки #инструменты

useEffect vs useLayoutEffect

Статья (англ.): https://kentcdodds.com/blog/useeffect-vs-uselayouteffect

Маленькое напоминание о разнице между двумя хуками.

useEffect срабатывает асинхронно после рендера компонента - пользователь уже увидел обновленный интерфейс, и только потом исполняется ваш код.

useLayoutEffect срабатывает синхронно. Новый DOM уже подготовлен, но браузер еще не перерисовал страницу для пользователя. В этот момент исполняется ваш код.

Обычно нам нужен useEffect, так как он неблокирующий и более эффективный, а у useLayoutEffect есть вполне конкретные кейсы:

- снять метрики (позиция скролла)
- обновить DOM до перерисовки так, чтобы пользователь не увидел мерцания
- установить какие-то актуальные значения, чтобы весь последующий код из useEffect мог их использовать

#ссылки #жизненныйциклкомпонента #хуки

React 19 будет компилируемым

Статья (англ.): https://reacttraining.com/blog/react-19-will-be-compiled

В феврале разработчики React рассказали, что работают над компилятором (React Compiler), который добавит в React автоматическую мемоизацию и сделает жизнь разработчиков проще (пост тут).

А в статье автор разбирается, что же это значит и насколько это нововведение изменит разработку.

Зачем мы мемоизируем

Одним из важных отличий классовых компонентов от функциональных было то, что рендер был вынесен в отдельный метод класса. Там был только код рендера и больше ничего. Когда ваш компонент перерендеривался, он не дергал никакого лишнего кода, как это происходит сейчас с функциональными компонентами.

При каждом рендере у нас создаются новые функции, новые объекты, которые не равны тем, что были в предыдущем рендере, а значит, могут ненароком вызвать лишние рендеры дочерних компонентов. Чтобы избежать этого, мы используем всякие useCallback'и и useMemo - занимаемся ручной мемоизацией.

В статье приводится простой пример этого процесса.

Компилятор вроде как должен избавить нас от этой мороки, будем надеяться, что эта задумка будет удачной.

Чуть более компилируемый

Затем автор рассуждает немного о "компилируемости" React. Он приходит к заключению, что нет двух отдельных положений - либо компилируется, либо не компилируется. Компилируемость - это шкала, на которой одни инструменты (Svelte) более компилируемы, а другие менее.

Идея в том, что появление нового компилятора не должно нас пугать.

#ссылки

Использование forwardRef с generic-компонентами

Статья (англ.): https://www.totaltypescript.com/forwardref-with-generic-components

Если вы часто используете generic-компоненты (которые могут работать с разными типами данных), то возможно уже сталкивались с проблемой с пробрасыванием рефа.

Если обернуть такой компонент в функцию React.forwardRef, то внутри него перестают выводиться типы.

👉 Компонент:

const Table = <T>(
  props: {
    data: T[];
    renderRow: (row: T) => React.ReactNode;
  },
  ref: React.ForwardedRef<HTMLTableElement>
) => {
  return (
    <table ref={ref}>
      <tbody>
        {props.data.map((item, index) => (
          <props.renderRow key={index} {...item} />
        ))}
      </tbody>
    </table>
  );
};
 
const ForwardReffedTable = React.forwardRef(Table);

👉 Использование:

<ForwardReffedTable
  data={[1, 2]}
  renderRow={(row) => {
    return <tr />;
  }}
/>

Мы передаем массив чисел в проп data и ожидаем, что для параметра row выведется правильный тип number, но этого не происходит.

👉 Решение:

Автор статьи предлагает сделать обертку над React.forwardRef, чтобы пофиксить это.

function fixedForwardRef<T, P = {}>(
  render: (props: P, ref: React.Ref<T>) => React.ReactNode
): (props: P & React.RefAttributes<T>) => React.ReactNode {
  return React.forwardRef(render) as any;
}

👉 Дополнительно:

- Перенаправление рефов

#ссылки #рефы

useActionState

В репозиторий реакт пару недель назад слили PR, в котором был немного изменен хук useFormState. Честно говоря, этот хук прошел полностью мимо меня, поэтому читаю как про совершенно новый хук)

Итак, у нас был какой-то useFormState, а стал useActionState, потому что все путались и думали, что можно работать только с формами. Оказывается, можно работать с любыми асинхронными экшенами.

Основная идея хука - отслеживать состояние экшена. Он возвращает три параметра:

const [state, action, isPending] = useActionState(someAsyncAction)

Action

action - это запуск экшена. То есть вместо того, чтобы напрямую вызывать someAsyncAction, мы вызываем предоставленный им action, так как в нем есть полезные оберточки.

Вызвать его можно прямо:

async function handleAction() {
  await action(someData)
}

А можно и традиционно засунуть в форму:

<form action={action}>

isPending

Как только запустился action, параметр isPending становится равен true. Как только action закончит свое выполнение, isPending станет false.

Таким образом мы можем отслеживать состояние экшена, работает он прямо сейчас или нет.

state

state - это результат работы экшена, то, что он вернул. Если вызовов было несколько, то результат работы последнего вызова.

Тут вроде ничего сложного нет, раньше мы самостоятельно накручивали подобный функционал вокруг какого-то вызова функции, теперь его накрутили за нас.

Конкуррентный рендеринг

Из приятного - под капотом используются transitions, то есть конкуррентный рендеринг.

Код выше можно переписать примерно вот так:

const [state, setState] = useState(null)
const [isPending, startTransition] = useTransition()

function handleAction() {
  startTransition(async () => {
    const response = await someAsyncAction({ userId: 222 })
    setState(response)
  })
}

Подводные камни

Есть и сложности, куда без них.

Так как неизвестно, используется ли isPending, он всегда устанавливается перед вызовом экшена, что приводит к дополнительному обновлению стейта (та же проблема есть и у хука useTransition).

#ссылки #хуки