Вход — контракт и ограничения
Вход должен содержать публичную схему или обезличенное синтетическое описание API, допустимые состояния ответа, правила валидации и ограничения среды выполнения. Зафиксируйте, разрешены ли сетевые обращения, какие зависимости доступны и какие свойства намеренно не проверяются. Все fixtures должны быть синтетическими и не должны включать секреты, персональные данные, production payload или частные логи. Не выводите значения ключей; для авторизации используйте только имена переменных окружения, например ${API_KEY}.
Матрица тестовых случаев
Для каждого случая укажите уникальный идентификатор, цель, точный fixture, предварительные условия, ожидаемый результат, наблюдаемое утверждение и источник ожидания в пределах переданного контракта. Разделяйте успешные случаи и ошибки валидации, транспортные ошибки, тайм-ауты, некорректный JSON, пустые и отсутствующие поля, граничные значения Unicode и неожиданные типы. Если контракт не определяет поведение, помечайте его как неподтверждённое предположение, а не выбирайте результат самостоятельно.
Изоляция и запрет внешней сети
Опишите, как тесты должны работать без внешней сети: используйте локальный mock или заранее заданный адаптер, а сетевой клиент заменяйте контролируемым doubles-объектом. Добавьте отдельный тест, подтверждающий, что попытка сетевого обращения отклоняется или перехватывается согласно настройке среды. Не выполняйте реальные и платные запросы. Если способ блокировки сети не задан, отметьте это как пробел реализации.
JSON, кодировки и границы данных
Предложите синтетические проверки для корректного и некорректного JSON, лишних или отсутствующих полей, неожиданных типов, пустых строк, нулевых значений и предельных размеров, только если такие ограничения заданы контрактом. Отдельно рассмотрите Unicode: неразрывные символы, комбинируемые знаки, эмодзи, разные формы нормализации и ошибки декодирования. Поведение библиотек Python json или codecs можно использовать как область для проверки, но нельзя переносить его на конкретный API без подтверждения контрактом.
Отчёт о неопределённости и покрытии
В конце сформируйте списки: подтверждённые контрактом ожидания, неподтверждённые предположения, непроверяемые свойства и необходимые уточнения. Отдельно укажите, что план не подтверждает production-поведение, нагрузочные характеристики, безопасность серверной инфраструктуры, доступность внешних зависимостей, поведение необъявленных версий SDK и успешный запуск тестов. Не заявляйте о покрытии или результатах выполнения, если код не был фактически запущен в описанной среде.
Минимальный синтетический пример
Для вымышленного контракта ниже поле ok обязано быть boolean, а items — массивом. Строка "true" не заменяет boolean. В примере задано ожидаемое отклонение именно контрактным валидатором: JSON сам по себе синтаксически корректен. Это проект теста, не отчёт о его выполнении; к реальному API данный результат не относится.
{
"contract": {
"ok": "boolean",
"items": "array"
},
"fixture": {
"ok": "true",
"items": []
},
"expected": {
"stage": "schema_validation",
"result": "reject",
"reason": "ok must be a boolean"
}
}Шаблон промпта
Составь контрактный тест-план по публичному описанию API ниже. Используй только синтетические fixtures и локальные контролируемые замены; не используй production payload, персональные данные, пользовательские логи, реальные токены или внешнюю сеть. Если требуется авторизация, указывай только переменную окружения, например ${API_KEY}, без её значения.
Для каждого тестового случая укажи:
1. идентификатор и проверяемое свойство;
2. точный синтетический fixture;
3. предварительные условия и настройки изоляции;
4. ожидаемое состояние или тип ошибки;
5. точное наблюдаемое утверждение;
6. источник ожидания в переданном контракте либо пометку «не определено».
Раздели случаи на успешные ответы, ошибки валидации, транспортные ошибки, запрет внешней сети, некорректный JSON, границы Unicode и неожиданные типы данных. Не смешивай ошибки разбора, кодировки и транспорта в один случай. Добавь отдельную проверку того, что сетевые вызовы не выполняются. Для JSON и кодировок описывай только проверяемые границы; не утверждай гарантии конкретного API на основании поведения стандартной библиотеки Python.
В конце перечисли неподтверждённые предположения, пробелы публичного контракта и свойства, которые этот план не проверяет. Не придумывай статусы, форматы ошибок, SLA, совместимость SDK или иные гарантии, отсутствующие в контракте. Не выполняй запросы, не используй платные операции и не утверждай, что тесты запускались или прошли. Публичный контракт:
[ВСТАВЬТЕ ПУБЛИЧНУЮ СХЕМУ И ОГРАНИЧЕНИЯ]