Юнит-тестирование фронтенд-кода (вероятно) бесполезно

В Aista мы любим модульные тесты. Magic и его сателлитные проекты имеют 1,000+ юнит-тестов, а некоторые из сателлитных проектов даже имеют 100% покрытие юнит-тестами. Статический анализ кода с помощью автоматизации (да!) очень важен для нас. Однако юнит-тестирование фронтенд-кода — это откровенно (возможно) смешно.

Юнит-тесты предназначены для небольших логических единиц, чтобы автоматически убедиться, что ваш код (все еще) валиден, когда вы его рефакторите и/или добавляете в него функции. Если вы помещаете логику, требующую модульного тестирования, в код фронтенда, вы, вероятно, делаете что-то не так.

90% всех проектов, с которыми я работал в своей профессиональной жизни, были инструментами администрирования предприятий, и/или веб-сайтами для клиентов, узлами, регистрационными формами и т.д. Если вы помещаете бизнес-логику в эти фронтенд-проекты, вы рискуете тем, что какой-нибудь умник изменит полезную нагрузку JSON, обойдя вашу бизнес-логику, получив доступ к тому, к чему не должно быть доступа. Поэтому вы должны поместить свою бизнес-логику, потоки, валидаторы и т.д. в код бэкенда. Дублирование некоторых небольших частей этого во фронтенде, например, наличие валидаторов, предотвращающих передачу фиктивной полезной нагрузки для экономии пропускной способности — это нормально. Но добавление бизнес-логики во фронтенд до такой степени, что фронтенд требует модульного тестирования для проверки того, что его логика все еще работает — это либо избыточное дублирование кода до такой степени, что вы фактически создали свое приложение «дважды», либо, если вы делаете это только во фронтенде, откровенное безумие!

Есть некоторые исключения из этого правила, например, приложения с тяжелым фронтендом, требующие огромного количества сложного фронтенд-кода. Примером может служить Canva из реального мира, которая имеет 95% своего «ценностного предложения» во фронтенде, позволяя людям создавать изображения, презентации, полностью с нуля, почти как урезанная версия Photo Shop. BTW, Canva — это потрясающий инструмент, если вы еще не пробовали его. Однако большинство корпоративных приложений не должны иметь в своих фронтендах бизнес-логику и другие виды логики, для обеспечения их корректности требуется модульное тестирование. А если в таких проектах есть модульные тесты, то их модификация и поддержка становятся только сложнее благодаря наличию модульных тестов. И независимо от того, сколько юнит-тестов у вас в проекте, они никогда не заменят интеграционное тестирование и/или QA-тестирование, проводимое людьми.

Первое, что я делаю каждый раз, когда создаю новый компонент Angular, это удаляю файл «spec» — потому что если бы он был мне нужен в первую очередь, кто-то должен был бы ударить меня по лицу… 😉

Оцените статью
devanswers.ru
Добавить комментарий