Обзор библиотеки react-testing-library

[k12th]

Черный козёл на КДПВ какбэ намекает, какой чёрной магией предстоит заняться читателю...

[ru_vds]

Поменяли картинку

[k12th]

Про эту я тоже могу пошутить, но не буду вас мучить:)

[shir]

Вот с тех пор как начал писать что-то с использованием реакта (да и вообще фронтенд SPA на JS) столкнулся с тем что нет библиотек для функционального тестирования. Вот это первое что нравится (но далеко не идеальное). В идеале хочется capybara на js.

[FoterIS]

Чем-то Selenium напомнило. Только тестируется не весь сайт. А только конкретный компонент

[vintage]

Автор не совсем прав или совсем не прав. Пользователь не ищет поле по тексту «Имя», чтобы ввести имя. Пользователь сканирует элементы и видит запрос имени. Сам текст запроса может быть любым: «Имя», «Введите имя», «Ваше имя», «Name» или вообще иконка. Текстовые константы имеют свойство меняться, не влияя на функциональность. Поэтому, если мы завязываемся на выводимые пользователю тексты, то получаем хрупкие тесты.

Далее, так как дерево компонент рендерится целиком, то тесты более высокоуровнего компонента начинают зависеть от деталей реализации низкоуровневых. Это приводит к тому, что рефакторинг любого компонента (без изменения его апи) с весьма не нулеевой вероятностью ломает тесты всех косвенно использующих его компонент. То есть тесты опять же получаются хрупкими.

Когда у вас несколько элементов с одинаковыми текстами, вообще начинается цирк с конями.

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

[justboris]

Вы статью внимательно прочли? Для таких случаев предлагается использовать data-testid и функцию getByTestId.

[vintage]

О том и речь, что нет случаев, когда стоит использовать что-то кроме неё. И правильный фреймворк генерирует эти идентификаторы автоматически на основе семантики.

[justboris]

Ни React, ни Vue никаких идентификаторов автоматически не генерируют.
"Правильный фреймворк" — это, видимо, тот самый $mol. Ясно-понятно.

[vintage]

На базе того же реакта можно собрать фреймворк, который будет их генерировать. Насколько вуй можно пропатчить в эту сторону я не знаю. Ну а в $mol это идёт из коробки, да. И именно поэтому у него такой странный синтаксис смещающий акцент с типов на семантику. Типичный html-шаблон, где забыли/поленились расставить идентификаторы:

<button class="btn">Load</button>
<button class="btn">Save</button>
<button class="btn">Reset</button>

Как сделать Reset красным? Как в тесте нажать на Save? Как узнать в фокусе ли сейчас Load?

Для стилизации добавляют либо визуальные классы типа "btn-danger", либо таки семантические "load", "save", "reset". В тестах завязываются либо на текст, либо таки добавляют семантические идентификаторы. Ну а для получения состояния вложенного компонента либо либо подписываются на события и хранят состояние самостоятельно, либо таки находят компонент по идентификатору и спрашивают его свойство.

Получаем, что качественный код не просто может, он обязан иметь уникальный семантический идентификатор и менно он имеет наибольшее значение, а не тип или визуализация. Именно поэтому во view.tree нельзя не написать идентификатор чисто синтаксически:

<= Load $mol_button sub / \Load
<= Save $mol_button sub / \Save
<= Reset $mol_button sub / \Reset

Этот идентификатор позволяет и стили навесить:

[my_app_load] {}

И найти элемент для теста:

app.Load().dom_node()

И узнать любые свойства любого компонента:

app.Load().focused()