Комментарии 1
Мне кажется, вы смешиваете end-to-end и unit тесты в кашу
— Unit тесты должны проверять, что код работает, и работает так, как задумано разработчиком
— end-to-end тесты проверяют пользовательский путь и сценарии
Вот в e-2-e можно тестировать пользовательский путь, забыть о метриках и просто на кнопочки нажимать. И скриншотное тестирование внедрить, например. Ему абсолютно не важно, какие у вас там функции откуда импортируются, с какими аргументами вызываются, какие атрибуты есть у тегов и так далее. Главное, чтоб сценарий пользователя проходил успешно и вёрстка не ехала (если есть скриншоты)
А unit-тесты, ИМХО, должны выглядеть так, чтоб я по ним мог понять, как именно работает компонент, удалить его и написать новый один в один, ничего не сломав. С вашим тестом из примера я затрудняюсь так сделать
— Unit тесты должны проверять, что код работает, и работает так, как задумано разработчиком
— end-to-end тесты проверяют пользовательский путь и сценарии
Вот в e-2-e можно тестировать пользовательский путь, забыть о метриках и просто на кнопочки нажимать. И скриншотное тестирование внедрить, например. Ему абсолютно не важно, какие у вас там функции откуда импортируются, с какими аргументами вызываются, какие атрибуты есть у тегов и так далее. Главное, чтоб сценарий пользователя проходил успешно и вёрстка не ехала (если есть скриншоты)
А unit-тесты, ИМХО, должны выглядеть так, чтоб я по ним мог понять, как именно работает компонент, удалить его и написать новый один в один, ничего не сломав. С вашим тестом из примера я затрудняюсь так сделать
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование Реакт UI компонентов