теста, чтобы мокать как можно меньше данных? по факту это нарушает концепцию интеграционного теста когда тестируется определенный use case, но при этом упрощает само написание теста. ну и минус в том что при переносе компонента на другую страницу тесты сломаются.
p.s. речь о кейсе когда на странице не очень много бизнес логики. по-моему когда надо получить минимальными усилиями более менее уверенность в работоспособности страницы, это идеальный вариант
Да так норм, это у тебя e2e тесты критических сценариев получаются. Обычно сочетают юнит тесты+интеграционные тесты+е2е тесты. Если тебе нужно протестить какой-то конкретный компонент, то юнит, если надо связку компонентов это уже интеграционный. А если прям страницу целиком то это уже е2е. Нет ничего плохого чтобы юзать только е2е тесты например, но сам понимаешь, более низкоуровневых проблем они тебе не покажут, зато критический сценарий пользователя точно отработают
ну юниты для компонентов это дублирование тестов. потому что у нас одно и то же будет тестироваться как на уровне интеграционных так и на уровне юнитов
ну при рефакторинге компонента упадут интеграционные где используется этот компонент
к примеру, тебе необходимо проверить, что при возникновении ошибки (сработала валидация на поле), поле становится красным, интеграционный тест за это не отвечает, его обязанность протестить взаимодействие модулей
хороший кейс да но, наверное, не такой критичный с точки зрения экспериенса юзера.
так вот из таких мелочей и складывается юнит тест, в этом его цель
да, согласен, спасибо
Обсуждают сегодня