Юнит-тесты и фронтенд



Самое сложное место для автоматизированного тестирования — интерфейсы. Сложность тестирования проистекает от их асинхронной природы — ты никогда не поймешь, почему в тесте не нажимается кнопка: потому что она еще не загрузилась из-за задержки в браузере, или потому, что ее действительно сломали в последнем коммите.



С юнит-тестами тоже все плохо — фронтовый код сложно разбивать на вменяемые куски, которые приятно тестировать. Спасает только TDD и хорошие библиотеки типа vue.js, которые сводят количество процедурного кода к минимуму.



Сложность тестирования обостряет извечную проблему для проектов с плохим покрытием — регрессии.



Мой любимый способ борьбы с плохим покрытием на фронте — писать поменьше кода. Серьезно — максимум логики из фронтенда нужно уносить на бекенд: там живут достаточно взрослые и удобные технологии, на которых тесты писать легко и приятно.



Мы в mtrl.ai прямо запрещаем писать бизнес-логику на фронте. Если код в интерфейсе ходит в один эндпоинт, а в зависимости от результатов ходит в другой эндпоинт — это уже не очень хороший код. Если эндпоинта три — мы этот код не пропускаем.