И как их протестировать
Библиотека тестирования — популярная библиотека, облегчающая тестирование компонентов фронтенда с помощью различных утилит. И если вы знакомы с ним, вы также знакомы с getByTestId — довольно удобным способом нацеливания на элементы в DOM, чтобы подтвердить их существование. Когда я впервые узнал о тестировании компонентов React, я выбрал getByTestId. Просто добавьте атрибут data-testid к своему элементу и запросите его в своих тестах. Это может выглядеть примерно так:
Компонент
Тест
Но что это на самом деле говорит нам о том, что title отображается пользователю? Ничего. Мы просто утверждаем, что элемент заголовка существует. Это значение может быть любым, и уж точно не тем, что ожидает пользователь.
Этот тест может иметь больше смысла в контексте родительского компонента Project, где мы можем захотеть подтвердить, что проект был загружен с запросом заголовка выше. В любом случае, это значение может быть любым, и наш тест все равно будет пройден.
Когда мы тестируем наши компоненты React, мы должны стремиться тестировать их так же, как пользователи будут с ними взаимодействовать, и, таким образом, проверять значения, которые они увидят, или действия, которые они будут выполнять. Пользователей не интересуют атрибуты данных или classNames. Сами создатели библиотеки тестирования выступают за то, чтобы запрашивать элементы различными способами, кроме data-testid, если это возможно:
В духе руководящих принципов рекомендуется использовать это только после того, как другие запросы не работают для вашего варианта использования. Использование атрибутов data-testid не похоже на то, как используется ваше программное обеспечение, и его следует по возможности избегать.
Библиотека тестирования
Предположим, что потребитель компонента Project вместо этого передает описание проекта в качестве свойства title. Приведенный выше тест все равно пройдет, потому что присутствует data-testid.
Но эта проблема не похожа на data-testid . Вы можете оказаться в похожей ситуации, протестировав className или настраиваемый атрибут.
«Другие запросы»
В этой документации библиотеки тестирования упоминается, что использование data-testid следует использовать почти в крайнем случае. Но важно отметить, что его использование не всегда плохо, это просто зависит от того, для чего вы его используете. Например, запуск утверждения о том, что заголовок отображается на основе существования adata-testid, не идеален, но, допустим, вы хотите просто получить элемент, чтобы затем выполнить над ним определенное действие, например, событие щелчка. Никакого риска, связанного с этим, нет. На основании этого ваш тест не проходит и не проваливается, в отличие от приведенного выше примера. Ниже вы увидите пример того, где этот атрибут особенно полезен и безопасен.
Однако для всех других сценариев я стремлюсь протестировать с использованием тех других запросов, упомянутых в документах, — начиная с тех, которые доступны всем, среди них — getByRole, getByLabelText, getByText.
getByRole
Особенно полезно с button элементами, есть много других элементов, которые вы можете запрашивать по их роли, хотя заголовок является одним из них. Согласно библиотеке тестирования, это должен быть ваш лучший выбор, поскольку с его помощью вы можете запрашивать практически все что угодно.
getByLabelText
Особенно полезно для форм, но они также принимают aria-label атрибутов.
получить по тексту
Полезно при поиске неинтерактивных элементов, таких как div, span и параграфы.
byText было бы отличным вариантом в приведенном выше примере. Это будет означать, что пользователь видит предполагаемый заголовок.
Как низко ты можешь пасть?
Ранее я упоминал, что нежелательное поведение прохождения теста на основе его data-testid, когда фактические данные неверны, не имеет ничего общего с этим атрибутом. И вы правы, думая, что это также могло бы произойти при запросе с помощью aria-label (если бы вы предоставили для него фиксированное жестко запрограммированное значение).
Предположим, мы хотим протестировать палитру цветов (представьте себе что-то вроде Pages или Microsoft Word, где у нас есть список различных цветов, но у нас также есть раздел «избранное» или «недавно использованные» цвета в другом палитре). . Мы хотим проверить, что при выборе цвета из палитры он добавляется в раздел недавно использовавшихся.Для этого мы автоматически предполагаем, что в палитре будет два вхождения одного и того же цвета (одно в общем списке все цвета и один в недавно использовавшемся разделе.) Тогда, возможно, стоит убедиться, что мы запрашиваем сам недавно использованный раздел, чтобы проверить существование цвета.
Вот тут-то и появляется мой любимый запрос — within
within позволяет проверять наличие определенных элементов внутри других элементов. Это может выглядеть примерно так:
С помощью within мы повысили точность и смоделировали поведение пользователя. Это оставляет мало места для ошибки.
Я также упоминал ранее, что в некоторых случаях getByTestId не так уж рискованно. Приведенный выше тест является одним из таких случаев. Я извлекаю элемент через его data-testid, чтобы затем углубиться и найти его дочерний элемент, но мое тестирование не проходит или не проходит на основе самого этого раздела.
Краткое содержание
Важно тестировать наши компоненты так же, как с ними будут взаимодействовать пользователи, включая проверку ожидаемых данных и избегание их атрибутов data-testid. Хотя в некоторых случаях это неизбежно, проверка существования данных с использованием этих атрибутов может привести к ложным срабатываниям, если мы передадим неверную информацию.
Документация библиотеки тестирования предлагает использовать getByRole большую часть времени, так как это подберет большинство элементов, если они доступны, а getByText и getByLabelText чрезвычайно полезны. Если бы мы хотели быть очень точными и проверять, что определенные элементы вложены в определенные элементы, мы могли бы использовать помощник within для повышения точности.
