Тестирование во фронтенде: почему тестовое окружение нужно заносить сразу
Что настраивают на старте проекта — и что забывают
Разворачивая новое фронтенд-приложение, команда почти рефлекторно заносит привычный набор: линтеры, pre-commit хуки, TypeScript, UI-кит. Всё это делается на старте и не обсуждается — так принято.
А потом раз за разом забывают об одном и том же: подготовить тестовое окружение.
Тесты оказываются той задачей, которую откладывают до момента, когда «будет время». Времени не появляется никогда, а цена отложенного решения растёт с каждым спринтом. Ниже — четыре причины, почему тестовое окружение стоит заносить в проект вместе с линтерами, а не после релиза.
Причина первая: тесты нужны в первую очередь самому разработчику
Разработчик и так прогоняет написанный код в голове — раз за разом, на соответствие требованиям клиента. Каждый новый кейс добавляется к предыдущим, и в какой-то момент удерживать их все становится физически невозможно.
Это и есть главный аргумент за автоматизацию: набор проверок, который вы держите в голове, можно выгрузить в инструменты, доступные каждому. Тест — это не бюрократия ради галочки в чек-листе, а способ перестать быть единственным местом хранения знаний о том, как система должна себя вести.
Причина вторая: контроль регрессий
Формулировка короткая: не ломайте то, что уже работает.
Сломанный код не должен доезжать до деплоя. Между коммитом и продакшеном нужны «ворота качества» — quality gate, — через которые прогоняется весь фронтенд-код. Одним из звеньев этих ворот должны быть юнит-тесты.
Без такого барьера каждая новая фича становится лотереей: работающая функциональность ломается незаметно, а узнаёте вы об этом от клиента. С автоматическим прогоном тестов регрессия отлавливается до того, как изменения покинут ветку.
Причина третья: тесты меняют код-ревью
Тесты помогают на review и вскрывают неучтённые кейсы.
Если в команде выстроена культура разработки, ревью начинается именно с тестов: они показывают, какое поведение автор считал правильным, и сразу делают видимыми пробелы — сценарии, которые никто не предусмотрел.
Отдельный эффект проявляется ещё раньше, на этапе написания кода. Баги находятся именно в момент написания теста. Казалось бы, повод расстроиться — но на деле это лучший из возможных сценариев: вы правите проблему, пока пишете код, а не когда заказчику приходит гневное сообщение от клиента.
Разница в стоимости этих двух ситуаций и есть главный экономический аргумент за тесты.
Причина четвёртая: тестируемость дисциплинирует архитектуру
Тестирование предполагает, что код удобен для тестирования. Удобен далеко не всякий код.
У каждого фреймворка свой подход, но кое-что остаётся неизменным:
- декомпозируйте— крупные неделимые куски логики не поддаются проверке по частям;
- уменьшайте логические взаимосвязи— чем меньше связность, тем меньше нужно поднимать окружения ради одного простого кейса.
Требование тестируемости работает как постоянное давление в сторону более чистой архитектуры. Код, который легко покрыть тестами, обычно оказывается и проще в поддержке — просто потому, что обе задачи требуют одного и того же: понятных границ между частями системы.
С чего начать внедрение
Порядок шагов простой, и первый из них — не технический.
- Придите к своей команде и договоритесь.Тестирование не внедряется одним разработчиком в своей ветке. Пока команда не согласилась, что тесты — часть определения готовности задачи, любое покрытие останется личной инициативой одного человека и умрёт при первом же горящем дедлайне.
- Подготовьте окружение.Это работа в связке с DevOps: поднять CI и сделать так, чтобы тесты прогонялись автоматически, без ручного запуска.
- Возьмите готовый рецепт фреймворка.Любой современный фронтенд-фреймворк предоставляет свою рецептуру для тестирования — искать нестандартное решение на старте не нужно. Возьмите документацию и начните применять на практике.
Ключевое здесь — автоматический прогон. Тесты, которые нужно запускать руками, перестают запускаться примерно через две недели.
Тестирование как стандарт услуги
Держать фронтенд-репозиторий в чистоте и покрытым тестами — это не личная особенность отдельного разработчика, а обязанность команды.
Внедрение процессов тестирования как стандарта в разы повышает качество услуг компании. Для студии, которая делает проекты на заказ, это переводится в понятную вещь: предсказуемость. Клиент получает не обещание, что «всё работает», а процесс, в котором сломанный код не доезжает до продакшена по техническим причинам, а не потому, что кто-то внимательно посмотрел.
Начать можно с одного разговора с командой — а дальше с одного теста в CI.
Материал подготовлен по видео We Wizards «Тестирование как базовый стандарт фронтенд-разработки».
