Хорошая подборка, особенно мысль, что статус-код не ловит чужой заказ и несписанный остаток. Для тех, кто хочет потренировать именно такие проверки, я сделал учебный API магазина: всё отвечает 200, но спрятано 10 багов — неверный итог, число строкой, лишнее поле с хешем пароля, ответ, который противоречит логу. Есть документация и проверка найденного прямо на странице: https://checkcraft.ru/guides/api-testing-practice.html (раскрою интерес: страница на сайте моего инструмента, для тренировки он не нужен).
«Документ провёлся, тест зелёный, а учёт разъехался» — очень точно. В API то же самое: статус 200, а сумма в ответе не та. Как вы ловите такое в регрессе: сверяете ОСВ руками после прогона или есть автоматическая сверка проводок с ожидаемыми? Кажется, самое дорогое здесь — что ожидаемый результат может сформулировать только человек с бухгалтерским опытом, и его хочется записать один раз, а не держать в голове.
Две минуты вместо часа на регресс после выноса сервиса — сильный результат. Как вы проверяли, что новый Pre-margin отвечает так же, как Core: прогоняли одинаковые запросы в оба и сравнивали ответы целиком или переносили автотесты как есть? При распиле часто всплывают расхождения в мелочах — порядок элементов, формат дат, округление, — которые старые тесты не проверяли, потому что в монолите они не менялись. Для калькулятора рисков округление особенно интересно.
Спасибо, кейс хороший: ожидаемые результаты конкретные, а блок «Открытые вопросы» — самое ценное, модель честно показала дыры в требованиях. Что бы я добавил:
TC-09 «подождать 15 минут» дорог в прогоне. Лучше заранее договориться о настройке времени блокировки на стенде и проверить границу: 14:59 — ещё нельзя, 15:00 — уже можно.
В TC-07 и TC-11 одинаковым должен быть не только текст на форме, но и ответ сервера: код, тело и примерно время ответа. Через разницу в API или во времени логины перебирают чаще, чем через интерфейс.
Не хватает кейсов: пять попыток одновременно (не обойдётся ли счётчик гонкой), продлевает ли блокировку попытка во время неё, блокировка по логину или ещё и по IP.
Третий пункт модель, кстати, могла бы найти сама, если в промпте попросить отдельно перечислить параллельные и временные сценарии.
Похожие есть: агент читает отчёт прогона и логи, но сам по стенду не ходит. А самым полезным оказалось другое ограничение: чинить локаторы и ожидания агенту можно, а менять ожидаемые значения в проверках — только через ревью человека. Это и закрывает риск «починить тест под баг»: если агенту для зелёного прогона нужно поменять число в assert, это уже повод смотреть продукт, а не тест.
Интересное решение — не давать агенту живую страницу и чинить локаторы по отчёту 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, и сгенерированные типы врут. Это ловится сравнением живых ответов со схемой в интеграционных тестах. Вы доверяете спецификации или проверяете ответы отдельно?
Хорошая подборка, особенно мысль, что статус-код не ловит чужой заказ и несписанный остаток. Для тех, кто хочет потренировать именно такие проверки, я сделал учебный API магазина: всё отвечает 200, но спрятано 10 багов — неверный итог, число строкой, лишнее поле с хешем пароля, ответ, который противоречит логу. Есть документация и проверка найденного прямо на странице: https://checkcraft.ru/guides/api-testing-practice.html (раскрою интерес: страница на сайте моего инструмента, для тренировки он не нужен).
«Документ провёлся, тест зелёный, а учёт разъехался» — очень точно. В API то же самое: статус 200, а сумма в ответе не та. Как вы ловите такое в регрессе: сверяете ОСВ руками после прогона или есть автоматическая сверка проводок с ожидаемыми? Кажется, самое дорогое здесь — что ожидаемый результат может сформулировать только человек с бухгалтерским опытом, и его хочется записать один раз, а не держать в голове.
Две минуты вместо часа на регресс после выноса сервиса — сильный результат. Как вы проверяли, что новый Pre-margin отвечает так же, как Core: прогоняли одинаковые запросы в оба и сравнивали ответы целиком или переносили автотесты как есть? При распиле часто всплывают расхождения в мелочах — порядок элементов, формат дат, округление, — которые старые тесты не проверяли, потому что в монолите они не менялись. Для калькулятора рисков округление особенно интересно.
Спасибо, кейс хороший: ожидаемые результаты конкретные, а блок «Открытые вопросы» — самое ценное, модель честно показала дыры в требованиях. Что бы я добавил:
TC-09 «подождать 15 минут» дорог в прогоне. Лучше заранее договориться о настройке времени блокировки на стенде и проверить границу: 14:59 — ещё нельзя, 15:00 — уже можно.
В TC-07 и TC-11 одинаковым должен быть не только текст на форме, но и ответ сервера: код, тело и примерно время ответа. Через разницу в API или во времени логины перебирают чаще, чем через интерфейс.
Не хватает кейсов: пять попыток одновременно (не обойдётся ли счётчик гонкой), продлевает ли блокировку попытка во время неё, блокировка по логину или ещё и по IP.
Третий пункт модель, кстати, могла бы найти сама, если в промпте попросить отдельно перечислить параллельные и временные сценарии.
Похожие есть: агент читает отчёт прогона и логи, но сам по стенду не ходит. А самым полезным оказалось другое ограничение: чинить локаторы и ожидания агенту можно, а менять ожидаемые значения в проверках — только через ревью человека. Это и закрывает риск «починить тест под баг»: если агенту для зелёного прогона нужно поменять число в assert, это уже повод смотреть продукт, а не тест.
Интересное решение — не давать агенту живую страницу и чинить локаторы по отчёту 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, и сгенерированные типы врут. Это ловится сравнением живых ответов со схемой в интеграционных тестах. Вы доверяете спецификации или проверяете ответы отдельно?