Интересное решение — не давать агенту живую страницу и чинить локаторы по отчёту CI. Сколько прогонов в среднем уходит, пока черновик теста станет зелёным? И как агент отличает падение из-за неверного локатора от настоящего бага в продукте? Есть риск, что он «починит» тест под баг.
Зацепил тезис, что тесты по API часто дают ложные результаты. По моему опыту, ложный «зелёный» чаще всего идёт от слабых проверок: тест смотрит на статус 200 и наличие поля, а не на его значение. Что имелось в виду в докладе: слабые проверки или расхождение между API и интерфейсом, когда API ответил верно, а на экране другое?
Самое ценное в истории — выгрузка через REST API, которую сняли «для другой задачи», а она оказалась единственным бэкапом. После этого случая вы сделали выгрузку регулярной, например по расписанию в CI? И проверяете ли, что из неё действительно собирается проект? Копия, из которой ни разу не восстанавливались, обычно подводит как раз в момент восстановления. И интересно, что оказалось с одним кейсом из 1539, который не совпал.
Спасибо, вы ответили как раз на второй вариант. Строка с ожидаемым значением в конце файла, которую тест читает сам, снимает вопрос, держать ли число в коде. А assert в конфиге ловит сломанное ожидание ещё при генерации, а не в упавшем тесте. Уточню одно: сохраняется ли «байт в байт» между версиями движка, если обновить сам tdcv2 при том же конфиге и зерне?
Спасибо, понятно. Прогон по папке точно пригодится: в больших проектах .http-файлы обычно раскладывают по сервисам. А если client.test станет блокирующим и прогон будет возвращать код выхода, клиент можно будет запускать в CI, как ijhttp у JetBrains.
Самое слабое место сгенерированных кейсов, по моему опыту, — ожидаемый результат. Модель охотно пишет «система возвращает корректный ответ» вместо конкретных значений, и такой кейс потом нельзя ни прогнать, ни автоматизировать. В воркфлоу можно добавить простой фильтр: кейс без конкретного ожидаемого значения (код ответа, поле, число) отправлять на доработку.
Интересно, какая доля кейсов у вас получалась с размытым ожидаемым результатом? Будет ли это в статье про подводные камни?
Принцип «известного ответа» хорошо переносится на тестирование API. Если заранее положить в базу данные, для которых сумма, количество или статус известны точно, проверка ответа превращается из «выглядит правдоподобно» в сравнение с конкретным числом.
Самое трудное на практике — держать ожидаемое значение в актуальном состоянии, когда меняется генерация. У вас ожидаемый ответ выводится из конфига автоматически или его приходится пересчитывать руками?
Хороший разбор: проверяющий оценивал честность описания, а не право агента на действие. Это две разные проверки, и их полезно разнести.
Факты и состояние можно проверять детерминированно: какие вызовы инструментов были, что изменилось в базе, был ли уточняющий вопрос, если подходящих заказов больше одного. Такое правило проверяется кодом, без модели. ИИ-проверяющему остаётся то, что формализовать трудно: полнота и понятность объяснения. Тогда ошибку из первого эпизода ловит обычная проверка, а не судья.
Вы пробовали такую связку или сознательно оставили всё одному проверяющему?
Формат .http рядом с кодом — сильный аргумент: коллекция лежит в git и меняется в том же PR, что и сам эндпоинт.
Два вопроса по реализации. Как у вас с секретами? В JetBrains их выносят в http-client.private.env.json и добавляют в .gitignore. Вы повторили это разделение? И есть ли проверки ответа, аналог client.test и client.assert, или пока только сохранение переменных? Многих в Postman держит как раз прогон коллекции с проверками, а не отправка запросов.
Добавлю к валидации спецификации: её стоит проверять в CI тем же линтером, что и на бэкенде, например Spectral или redocly lint. Иначе фронт узнаёт о сломанной схеме только при генерации типов.
Есть ещё одна типичная проблема: спецификация расходится с реальными ответами. В схеме поле обязательное, а сервер иногда отдаёт null, и сгенерированные типы врут. Это ловится сравнением живых ответов со схемой в интеграционных тестах. Вы доверяете спецификации или проверяете ответы отдельно?
Интересное решение — не давать агенту живую страницу и чинить локаторы по отчёту CI. Сколько прогонов в среднем уходит, пока черновик теста станет зелёным? И как агент отличает падение из-за неверного локатора от настоящего бага в продукте? Есть риск, что он «починит» тест под баг.
Зацепил тезис, что тесты по API часто дают ложные результаты. По моему опыту, ложный «зелёный» чаще всего идёт от слабых проверок: тест смотрит на статус 200 и наличие поля, а не на его значение. Что имелось в виду в докладе: слабые проверки или расхождение между API и интерфейсом, когда API ответил верно, а на экране другое?
Самое ценное в истории — выгрузка через REST API, которую сняли «для другой задачи», а она оказалась единственным бэкапом. После этого случая вы сделали выгрузку регулярной, например по расписанию в CI? И проверяете ли, что из неё действительно собирается проект? Копия, из которой ни разу не восстанавливались, обычно подводит как раз в момент восстановления. И интересно, что оказалось с одним кейсом из 1539, который не совпал.
Спасибо, вы ответили как раз на второй вариант. Строка с ожидаемым значением в конце файла, которую тест читает сам, снимает вопрос, держать ли число в коде. А assert в конфиге ловит сломанное ожидание ещё при генерации, а не в упавшем тесте. Уточню одно: сохраняется ли «байт в байт» между версиями движка, если обновить сам tdcv2 при том же конфиге и зерне?
Спасибо, понятно. Прогон по папке точно пригодится: в больших проектах .http-файлы обычно раскладывают по сервисам. А если client.test станет блокирующим и прогон будет возвращать код выхода, клиент можно будет запускать в CI, как ijhttp у JetBrains.
Самое слабое место сгенерированных кейсов, по моему опыту, — ожидаемый результат. Модель охотно пишет «система возвращает корректный ответ» вместо конкретных значений, и такой кейс потом нельзя ни прогнать, ни автоматизировать. В воркфлоу можно добавить простой фильтр: кейс без конкретного ожидаемого значения (код ответа, поле, число) отправлять на доработку.
Интересно, какая доля кейсов у вас получалась с размытым ожидаемым результатом? Будет ли это в статье про подводные камни?
Принцип «известного ответа» хорошо переносится на тестирование API. Если заранее положить в базу данные, для которых сумма, количество или статус известны точно, проверка ответа превращается из «выглядит правдоподобно» в сравнение с конкретным числом.
Самое трудное на практике — держать ожидаемое значение в актуальном состоянии, когда меняется генерация. У вас ожидаемый ответ выводится из конфига автоматически или его приходится пересчитывать руками?
Хороший разбор: проверяющий оценивал честность описания, а не право агента на действие. Это две разные проверки, и их полезно разнести.
Факты и состояние можно проверять детерминированно: какие вызовы инструментов были, что изменилось в базе, был ли уточняющий вопрос, если подходящих заказов больше одного. Такое правило проверяется кодом, без модели. ИИ-проверяющему остаётся то, что формализовать трудно: полнота и понятность объяснения. Тогда ошибку из первого эпизода ловит обычная проверка, а не судья.
Вы пробовали такую связку или сознательно оставили всё одному проверяющему?
Формат .http рядом с кодом — сильный аргумент: коллекция лежит в git и меняется в том же PR, что и сам эндпоинт.
Два вопроса по реализации. Как у вас с секретами? В JetBrains их выносят в http-client.private.env.json и добавляют в .gitignore. Вы повторили это разделение? И есть ли проверки ответа, аналог client.test и client.assert, или пока только сохранение переменных? Многих в Postman держит как раз прогон коллекции с проверками, а не отправка запросов.
Добавлю к валидации спецификации: её стоит проверять в CI тем же линтером, что и на бэкенде, например Spectral или redocly lint. Иначе фронт узнаёт о сломанной схеме только при генерации типов.
Есть ещё одна типичная проблема: спецификация расходится с реальными ответами. В схеме поле обязательное, а сервер иногда отдаёт null, и сгенерированные типы врут. Это ловится сравнением живых ответов со схемой в интеграционных тестах. Вы доверяете спецификации или проверяете ответы отдельно?