Чтобы развернуть новое веб-приложение, нужно проделать огромную техническую и творческую работу на фронтенде: занести линтеры, прекоммит-хуки, продумать типизацию, UI-Kit и много всего еще. Но многие забывают о подготовке тестового окружения, а это снижает скорость и качество разработки даже самой опытной команды. Можем ли мы в этом случае гарантировать клиенту, что выпускаемая фича не поведет себя непредсказуемо? Я считаю, что тестирование отдельных модулей приложения на ожидаемое поведение и проведение юнит-тестов должны стать стандартом любого процесса разработки. Давайте разберемся, почему.

Как тестирование может упростить жизнь вам и вашим клиентам?

Автоматизация и упорядочивание процессов

Мы раз за разом прогоняем в голове написанный нами код на соответствие требованиям клиента. Почему бы не облегчить себе жизнь и не перенести это на инструменты автоматизации, которые доступны всем?

Отслеживание регрессий

Не ломайте то, что уже работает, и не деплойте код, который сломан. Ваш код должен прогоняться через quality gate или «ворота качества». Одним из звеньев этих ворот должны быть Unit-тесты.

Ревью и поиск неучтенных кейсов

Если у вас хорошая культура разработки в компании, вы начнете свое ревью именно с тестов. Лично я часто находил баги в собственном коде только при написании тестов. Все делают ошибки, но всегда лучше пофиксить баг еще до того, как его заметит заказчик, и своевременное тестирование позволяет сделать это.

Поддержание удобства и чистоты кода

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

Повышение доверия со стороны бизнеса

Уровень вашей разработки будет гораздо выше в глазах заказчика, который знает, что 98% его приложения покрыто тестами и возможность непредвиденных кейсов практически исключена.

С чего начать?

Просто подойдите к своей команде и скажите: «Ребят, давайте начнем тестировать!»

Останется только подготовить к этому окружение: написать девопсам, поднять CI/СD и сделать тесты автоматически прогоняемыми. Каждый фреймворк, который вы используете, базово предоставляет рецепты по тестированию. Изучите их, обсудите с коллегами варианты развертки и скорее применяйте на практике! Обязанность каждой команды разработки — держать фронтенд-репозиторий и код чистым, удобным и тестируемым.

Что тестировать?

• UI 
  Тут всё просто — проверяем, насколько реализация нашей задачи соответствует дизайн-макету. Если у вас есть четкий гайдлайн по UI-Kit, то, скорее всего, у вас есть storybook. Если нет, то стоит задуматься о том, чтобы его поддерживать. Это упростит коммуникацию с командой дизайна и позволит проводить снепшот-тестирование на консистентность вносимых изменений. 
• Алгоритмы 
  Функции, сервисы, в общем всё, что выполняется в рантайме фронтового кода, может быть покрыто юнит-тестами. Это вид тестирования, при котором проверяются небольшие части кода, например, добавление товара в корзину или роли доступа на сайт.
• Тестирование в команде 
  Если у вас есть тестировщик, который уже написал тест-кейсы на задачу, вы можете провести Е2Е-тестирование как дополнительную проверку качества в вашем CI/CD. Обратите внимание на такие инструменты как percy.io | cucumber | puppeteer.
• Интеграции
  Как правило, интеграция не тестируется командой фронтенда, а отдатся в QA. С нашей стороны важно держать контракты с бекендом в актуальном состоянии и мокать ожидаемые ответы, опираясь на актуальный контракт.

Мы в We Wizards понимаем, что упуская тестирование из основных требований к развертыванию нового проекта, мы рано или поздно обязательно наткнемся на кучу багов и несоответствий. Внедрение процесса тестирования как стандарта в разы повышает качество услуг вашей компании, поэтому тестируйте и делайте ваш код поддерживаемым!