Тестирование и проверка

Определите успех до изменения

Задайте наблюдаемый критерий готовности. «Добавь контактную форму» менее точно, чем «сохрани корректную заявку, покажи подтверждение после сохранения и дай сотруднику увидеть новую запись».

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

Разные проверки подтверждают разное

• Форматирование, линтер и проверка типов находят определённые проблемы исходного кода.
• Автоматические тесты проверяют только охваченные ими случаи.
• Успешная сборка подтверждает возможность собрать приложение с этой конфигурацией.
• Ответ проверки здоровья означает, что ответил конкретный endpoint.
• Проверка в браузере оценивает отображение, взаимодействие и видимый результат.
• Проверка production относится к активированному релизу по публичному адресу.

Эти способы дополняют друг друга. Успешная сборка или HTTP 200 не доказывает сохранение формы, корректность прав на защищённом маршруте или доступность публичного Preview.

Amazi считает простыми задачи без написания или изменения кода, а также изменения кода объёмом примерно до 100 строк суммарно. Агент сам оценивает, сколько кода потребуется добавить, изменить или удалить; вам не нужно считать строки или определять категорию задачи. Размер существующего проекта не определяет объём работы. Для таких задач форматирование, ревью кода, линтер, проверка типов, написание и запуск тестов, сборка — всё это необязательно: Amazi самостоятельно выбирает полезные шаги и может завершить задачу без них. Если вам нужна конкретная проверка, явно попросите её выполнить. Более объёмные изменения кода требуют соответствующих проверок. Невыполненную проверку нельзя выдавать за успешную.

Пока выполняется сборка или проверка, Amazi может продолжать независимую работу, а затем получить результат. Для длительных команд проекта агент может выделить до пяти минут. Запуск команды ещё не означает успешную проверку: дождитесь её фактического результата.

Пройдите пользовательский сценарий целиком

Откройте нужную страницу в Preview. Проверьте обычный путь и подходящий случай ошибки. Для формы — корректный и некорректный ввод, затем результат после обновления. Для навигации — прямые URL и кнопки браузера «назад» и «вперёд», а не только переключение экранов.

Проверьте телефон и большой экран: доступность элементов управления и отсутствие переполнения. Для сценариев после входа используйте нужную роль: Пользователи и вход в приложение.

Используйте искусственные данные. Preview может писать в ту же базу, что и production, поэтому тестовые действия не становятся безвредными автоматически.

Перед публикацией

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

Попросите Amazi перечислить реальные проверки и непроверенные части. «Реализовано» не означает «опубликовано», а «опубликовано» — «проверены все сценарии».

После публикации откройте production-адрес и повторите короткую проверку изменённого поведения. Если развёртывание завершилось ошибкой, изучите диагностику перед повтором. См. Публикация и домены.

Если проверка заблокирована

Зафиксируйте точную причину и затронутый сценарий. При ошибке шлюза в Preview используйте Проблемы предпросмотра. Недоступность предпросмотра означает непроверенный результат в браузере, а не успешно пройденный тест.