Инструменты отладки и шаг, которого не хватает в большинстве конфигураций

Инструменты отладки по категориям и то, что каждый из них предполагает

Каждый из них исходит из того, что до сбоя вы уже добрались. А часы на самом деле уходят как раз на то, чтобы это допущение стало верным.

Недостающий шаг

Надёжное воспроизведение — самый ценный артефакт отладки и при этом тот, который реже всего существует. Без него вы гадаете, а с ним любой другой инструмент сразу начинает работать.

Воспроизведение становится надёжным тогда, когда оно записано в виде шагов с ожидаемым результатом, а не хранится у кого-то в голове. Записанное, оно может быть запущено снова, передано другому человеку и сохранено после исправления.

Почему с агентом, который пишет код, это важнее

Когда исправляет агент, расплывчатое описание вредит куда сильнее, чем в случае с человеком. Человек может догадаться по скриншоту, что вы имели в виду. Агенту нужны явно описанные последовательность действий и расхождение с ожиданием, а при меньшем он уверенно починит не то.

В каком порядке проверять

Если баг не объясняется сразу, есть последовательность проверок, которая приводит к ответу быстрее, чем следование первой гипотезе, — в основном потому, что первая гипотеза обычно про код, а ответ часто лежит не в коде.

Воспроизводится ли это с полностью чистого состояния. Если нет — дело в остаточном состоянии, и код неисправен не в том смысле, в каком вы думаете.

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

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

Три вопроса, несколько минут — и каждый ответ отсекает целый класс причин. Большая часть времени отладки уходит на изучение класса причин, который один из этих вопросов исключил бы сразу.

Сохраняйте воспроизведение после исправления

Кейс, который вы собрали, чтобы увидеть баг, — это и есть проверка, которая не даст ему вернуться. Большинство команд удаляют его вместе с веткой, поэтому тот же дефект всплывает через полгода, и никто его не узнаёт.

Ту же настройку можно выполнить в панели TestSprite, если вы предпочитаете ничего не устанавливать локально. Остальные возможности CLI описаны в репозитории CLI.

• GitHub App — это вебхук, который вы настраиваете в панели TestSprite. Он слушает событие деплоя, которое ваш пайплайн и так генерирует, поэтому в репозитории ничего менять не нужно.

• GitHub Actions встраивает этот шаг в ваш собственный workflow и настраивается из терминала.

Как TestSprite закрывает недостающий шаг

Он превращает воспроизведение в артефакт. Вы описываете последовательность действий и то, что должно быть верно в конце, а TestSprite прогоняет это на вашем развёрнутом приложении и сообщает, что произошло на самом деле. Это и есть тот шаг, наличие которого предполагает любой другой инструмент отладки.

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

И само воспроизведение переживает исправление. Оно остаётся в проекте и запускается при каждом изменении, так что тот же дефект уже не вернётся незаметно после того, как ветка влита, а обсуждение забыто.