Как проверять результат и разбирать ошибки

Программа запустилась — что это доказывает

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

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

Проверка глазами пользователя

После реализации add и done выполните в учебной папке:

python3 app.py --file demo.json add "Пройти урок"
python3 app.py --file demo.json list
python3 app.py --file demo.json done 1
python3 app.py --file demo.json list
python3 check.py

Команды с done 1 предполагают новый файл с первой задачей. Если вы уже использовали demo.json, возьмите другое имя и используйте его во всех командах. На последнем выводе первой задачи должен быть статус [x]. Это ручная проверка полного пути; автоматические тесты используют временные папки и не портят ваши данные.

В заготовке проверки разделены по функциям:

python3 -m unittest discover -s tests -p test_app.py -k TestAdd
python3 -m unittest discover -s tests -p test_app.py -k TestDone
python3 check.py

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

Какие случаи нужны

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

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

Посмотрите git diff и git status --short. Агент не должен удалять неудобный тест или заменять ожидание успехом без согласованного изменения требований. Если тест ошибочен, разберите его отдельно: покажите противоречие со спецификацией и подтвердите исправленное ожидание.

Ошибка как материал для исследования

Команда: python3 app.py --file sample.json done 99
Ожидалось: ошибка и неизменный файл.
Факт: код 0, файл стал пустым списком.
Воспроизведи на временном файле.
Сначала назови возможную причину и отличающий её опыт.
Затем добавь регрессионную проверку и сделай узкое исправление.

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

Самостоятельное задание

На отдельной копии эталона попросите агента убрать проверку пустого названия в реализации, сохранив тесты. Запустите комплект и найдите, какая проверка поймала ошибку. Верните исходный код из эталона и повторите запуск. Затем придумайте один случай, которого нет в комплекте.

Критерии и разбор

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

Дальше: Что такое харнесс и почему одного промпта мало.