Comments 7
Интересно упоминание интеграционных и e2e тестов тут что-бы общую картину о подходах к тестированию описать. А конкретных selenium и Cypress — как пройденных и отброшенных шагов?
Т.е. вы сами то в итоге отказались от интеграционных и e2e всё перенеся в unit?
Кстати, есть ещё один интересный подход, не затронутый вами — "ручное" исполнение кода должно генерировать тест, который потом мог-бы запускаться как unit. Что правда требует несколько иного подхода к написанию кода. Это я в цикле статей нашёл, в частности вот в этой. Они про серверную часть, но ведь никто не мешает подобное реализовать на клиенте.
получается да сейчас больше пишем на проекте юнит тесты. проект большой и получается есть необходимость именно в юнит тестах. в тестах для самих разработчиков. так как есть штат тестировщиков которые пишут автотесты и производят ручное тестирование. Нам надо на проекте быть увереным что мы не сломали логику показав кнопку что бы быстрее сделать функционал а не тыкая пол дня что бы эту кнопку потом не забыть вернуть на место. или просто подсунув данные в один из методов что бы он вернул нужные сейчас данные и дальше пилить фичи.
но на других личных проектах там использую щас интеграционое даже можно сказать e2e тесты . в частности библиотека для тестирования реакта shallowly . там текущее состояние распологает к таким тестам . и юнит там не щас уместны возможно в дальнейшем как разрастется.
Начинайте с юнитов — они дают максимум пользы за минимум времени
Вот это не всегда. Проекты, задачи и компоненты бывают сильно разные. Более разумное правило - осознавайте природу (специфику) вашего приложения и создавайте (а не просто конструируйте или копируйте) свой подход, ведь главная фишка очень похожа на эволюцию, копания двух встречных тоннелей - адаптировать + адаптироваться. Нет никаких "делай именно так!", есть только "думай своей головой!".
Есть где одна прекрасная книга - Владимир Хориков - Принципы юнит-тестирования.
Как я перестал бояться тестов и полюбил зелёный CI