Автоматические проверки помогают находить ошибки до того, как новая версия сайта попадёт к посетителям. Для этого проект проверяют перед публикацией: запускают тесты, проверяют сборку и просматривают изменения. Начать можно с короткого списка проверок, который запускается после каждого обновления кода. В статье разберём, что включить в этот список, как организовать проверку для небольшого проекта и что делать, если она обнаружила проблему.
Что проверять перед каждым обновлением?
Выберите проверки по тому, что сайт делает для клиентов. Для сайта-визитки важны доступность страниц, корректные ссылки и отправка формы. Для интернет-магазина добавятся корзина и оформление заказа. Начните с действий, из-за ошибки в которых бизнес теряет обращение или продажу.
Базовый набор обычно включает проверку синтаксиса и сборки проекта, автоматические тесты ключевых функций и проверку ссылок на ошибки. Если сайт адаптирован для телефонов, включите сценарий, который открывает важные страницы в мобильном размере окна. Проверки должны завершаться понятным результатом: например, список ошибок с указанием файла или теста.
- Сборка: проект собирается без ошибок после изменения кода.
- Основные страницы: главная, каталог или страница услуги открываются.
- Ключевое действие: форма отправляется, поиск работает или товар добавляется в корзину.
- Ссылки и ресурсы: нет сломанных ссылок и отсутствующих файлов, нужных странице.
Не пытайтесь сразу проверить каждый элемент сайта. Сначала добавьте тесты для одного-двух важных пользовательских сценариев, а затем расширяйте список по мере развития проекта. Подход к проверке сгенерированного кода разобран в материале как проверить ИИ-сгенерированный код перед публикацией сайта.
Как запустить проверки перед публикацией?
Удобно разделить процесс на два этапа. Первый запускается после изменения кода и быстро проверяет, что проект собирается и основные тесты проходят. Второй выполняется перед публикацией: он открывает тестовую версию сайта и проверяет сценарии, которые проходят посетители.
Если вы работаете через Git-платформу, настройте запуск проверок при отправке изменений в репозиторий. Если публикацию делает разработчик вручную, добавьте те же команды в инструкцию по выпуску и не переходите к выкладке, пока проверка не завершилась успешно. Для небольшого проекта подойдёт и простой скрипт, который запускает тесты по порядку и останавливается при первой ошибке.
Новую версию сначала проверяйте на отдельной копии сайта, а не на рабочей странице. На копии можно проверить обновление, не меняя страницу, которую сейчас видят клиенты. Подробности такого подхода есть в материале о настройке staging-копии сайта на VPS.
Заранее определите, что считается успешным результатом. Например: сборка проходит, тест формы завершён без ошибки, основные страницы открываются. Если проверка упала, сохраните сообщение об ошибке и исправьте причину до публикации. Не отключайте тест только потому, что он мешает выпуску: сначала выясните, что именно он обнаружил.
Как подключить проверки к вайбкодингу?
ИИ может менять несколько файлов за один запрос, поэтому перед принятием изменений проверяйте не только итоговый вид страницы, но и результат автоматических тестов. Попросите инструмент описать, какие файлы он изменил и какие проверки нужно выполнить. Затем запустите проверки самостоятельно или настройте их запуск в рабочем процессе проекта.
Полезно хранить инструкции рядом с кодом. В них запишите команды для сборки и тестов, перечень ключевых сценариев и порядок проверки перед публикацией. Тогда следующий запрос к ИИ можно сформулировать конкретно: изменить форму, сохранить её поведение и убедиться, что существующие тесты проходят.
Если проект проверяет несколько моделей или инструментов, оставьте единый набор тестов. Это помогает сравнивать изменения по одинаковым условиям. При смене модели пригодится проверка сайта после смены ИИ-модели без команды QA.
Какие ошибки мешают автоматической проверке?
- Проверять только сборку. Она подтверждает, что проект удалось собрать, но не гарантирует, что работает форма или другой важный сценарий.
- Сразу публиковать крупное изменение. Если тесты обнаружат ошибку, будет сложнее понять, какая часть обновления её вызвала. Разбивайте работу на небольшие изменения.
- Запускать тесты только вручную. В таком процессе легко забыть проверку перед выпуском. Подключите её к отправке изменений или включите в обязательный порядок публикации.
- Игнорировать нестабильный тест. Если один и тот же сценарий то проходит, то падает, найдите причину или исправьте сам тест. Иначе ошибки в его результатах перестанут помогать.
- Проверять только на компьютере. Откройте ключевые страницы и сценарии в мобильном размере окна, особенно если клиенты часто заходят с телефона.
На этой неделе выберите одно важное действие на сайте, например отправку формы, и опишите его шагами. Добавьте автоматическую проверку этого сценария, настройте её запуск перед публикацией и проверьте, что при ошибке сайт не обновляется. Затем постепенно добавляйте остальные страницы и функции, от которых зависит работа бизнеса.
