Давайте просто захардкодим query в виде строки. И все, что еще останется сделать, это создать JSON запрос с нашей query-строкой
Если используете Python, то можно попробовать hypothesis-graphql. Библиотека сгенерирует случайные запросы по схеме, в полученные от сервера ответы можно будет проверить на отсутствие ошибок.
Здравствуйте, судя по одному из скриншотов, вы используете Swagger UI и соответственно Open API. Рассматривали ли использование инструментов для автоматического тестирования по Open API схеме? Вроде Schemathesis, Dredd или REST-ler. Если да, то как бы вы сравнили их с Postman?
В Open API 2.0 ключ "example" используется в меньшем количестве мест, по сравнению с 3.0, а именно в schemaObject и fileSchema. Причем для генерации тестов можно использовать только первый. Schemathesis поддерживает "example" только в таких случаях для Open API 2.0, чтобы следовать спецификации.
Но! Поддерживаются расширения "x-example" и "x-examples" для всех мест где определены соответствующие "example" и "examples" из Open API 3.0.
Т.е. это может выглядеть так (я убрал некоторые части для краткости)
В целом такое происходит из-за того что когда Hypothesis сталкивается с падением теста, он пытается удостовериться что ошибка надежно воспроизводится. Если у него не получается, то он выводит это сообщение об ошибке.
Насколько я понял, это присходит, когда Hypothesis делает проверку при двух последовательно идущих одинковых запросах. Он ожидает, что ответ будет одинаковым (проверка идемпотентности), но в теле ответа меняется идентификатор сущности и он считает это ошибкой
С учетом встроенных проверок, различающиеся идентификаторы не должны вызывать проблему если они оба соответствуют схеме. Но я думаю, что в целом у вас верное понимание ситуации (особенно об идемпотентности)!
Чаще всего такое поведение связано с тем что внутреннее состояние тестируемого сервиса отличается в начале каждого "теста" (это может быть и последовательность запросов, если рассматривать stateful тестирование). Например, если имена сущностей в сервисе должны быть уникальные, то:
Запрос на создание сущности с именем Test, пришел 201й ответ несоответствующий схеме, но в сервисе сущность успешно создалась. Hypothesis зарегистрировал ошибку.
Hypothesis пытается воспроизвести эту ошибку отправляя такой же запрос как в предыдущем пункте. Получает 409 который уже соответствует схеме - предыдущая ошибка не воспроизводится
но может быть вы подскажете как сделать эту проверку корректно?
БОльшая часть такого рода проблем решается очисткой состояния приложения перед каждым тестом. В CLI это можно сделать при помощи хука before_call, в Python тестах через использования контекстного менеджера в теле теста (как рекомендуется в документации Hypothesis).
В зависимости от сложности тестируемого сервиса, добавление логики для очистки состояния может сильно замедлить тесты, но результаты будет легче воспроизвести.
Или как отключить проверку идемпотентности для этого конкретного теста
В данный момент, это логику напрямую не отключить, но я планирую сделать такую возможность (возможно даже включить это по-умолчанию)
Спасибо за тексты ошибок. Скорее всего там под капотом тоже используется валидация JSON Schema, только отдается конкретная ошибка из leaf узла где есть additionalProperties: false. В то время когда в jsonschema отдается ошибка из узла самого близкого к корню (т.е. oneOf). Скорее всего это можно будет решить легче чем я думал изначально, просто выбрав другую ошибку из дерева которое возвращает jsonschema :)
В данный момент Schemathesis использует jsonschema для валидации схем и выводит ошибку оттуда напрямую. Я однозначно хочу это улучшить - для этого есть отдельный issue (довольно долго уже висит). Вполне вероятно что будет проще написать валидацию напрямую чем использовать ошибки из jsonschema (которые особенно неприятно разбирать из-за того древовидной структуры ошибок которую эта библиотека отдаёт).
Я постараюсь вернуться к этой проблеме в ближайшее время.
Отдельно хочу сказать что эту валидацию можно отключить (--validate-schema=false), если нужно запустить тесты без учета валидности схемы.
На мой предвзятый взгляд - да. С точки зрения поиска дефектов Schemathesis дает намного больше возможностей чем Dredd. В основном за счет использования Property-Based тестирования и генерации данных даже если примеров в схеме нет. Так же Schemathesis полноценно поддерживает Open API 3 (в Dredd поддержка эксперементальная). Конечно, Dredd умеет какие-то вещи которые Schemathesis не умеет. Например поддержка API Blueprint и хуков на разных языках. В FAQ можно почитать немного более развернутое сравнение.
Если говорить о сравнении эффективности на реальных проектах, то можно посмотреть эксперименты одной из статей для ICSE 2022. Сама статья должна быть опубликована в декабре. Эксперименты включают тестирование различных приложений с Open API схемами через Dredd, Schemathesis и еще несколько проектов. Они измеряют покрытие кода в приложениях, ошибки в коде и т.д. Например в одном из экспериментов Schemathesis покрыл 65% кода (в строчках) бэкенда, а Dredd 38%. В некоторых примерах разница меньше, но в целом, в этих экспериментах Schemathesis показал больший или примерно такой же процент покрытия чем Dredd, даже учитывая тот факт, что использовалась довольно старая версия Schemathesis в которой еще не было негативного тестирования.
Рассматривали ли вы использование Hypothesis для генерации данных или других аспектов тестирования (например минимизации найденной ошибки)? В нем есть довольно много разных "стратегий" для генерации данных, включая строки, числа, списки, даты и тому подобное. Кроме этого они легко сочетаются друг с другом и позволяют генерировать практически произвольно сложные структуры данных.
Например, Schemathesis использует этот фреймворк в том числе и для того чтобы генерировать входные данные по Swagger 2.0 / Open API 3.0 / GraphQL схемам (а так же и данные которые не подходят под схемы).
Ну и третье, но, пожалуй, самое важное: ни один из таких инструментов не решает вопрос подготовки тестовых данных…
А что вы имеете ввиду под подготовкой тестовых данных? Если именно умение генерировать данные, то кроме вышеупомянутого инструмента, REST-ler и Cats (а так же некоторые другие проекты) тоже умеют генерировать тестовые данные без использования явных примеров из схем. Правда, они их не всегда умеют экспортировать их напрямую, а используют сразу при запуске инструмента.
FastAPI действительно хорош, но хочу отметить, что в данный момент (версия 0.54.1) он может генерировать схемы которые не являются корректными согласно спецификации Open API версий 3.0.x.
Это происходит из-за того, что pydantic, используемый в FastAPI для создания JSON схем использует Draft 7, а не Wright Draft 00 (aka Draft 05) указанный в Open API 3.0.x спецификациях.
Конкретная проблема заключается в ключевых словах exclusiveMinimum и exclusiveMaximum, значения которых в JSON Schema Draft 06 стали иметь тип number и до этого были boolean. Т.е. если схема от FastAPI включает себя эти ключевые слова, то они будут типа number, а не boolean, как должны быть согласно спецификации.
В Schemathesis это решается через специальную опцию командной строки --fixups=all, но по-умолчанию валидация не пропустит такую схему. В Open API 3.1 будет использоваться более новый Draft 2019-09 и конкретно эта проблема должна решиться. На стороне FastAPI так же существует issue посвященный этой проблеме
На данный момент в Schemathesis сгенерированные данные соответствуют схеме (если нет, то стоит завести баг репорт), но возможны ситуации когда приложение может посчитать их невалидными, например из-за дополнительных проверок которые не укладываются в саму схему и реализованы вручную в приложении.
Т.е. то что они расцениваются приложением как невалидные это больше особенность реализации конкретного приложения и его схемы чем намеренное поведение со стороны Schemathesis.
Тем не менее генерация невалидных данных у нас в плане на ближайшие пару месяцев
Если используете Python, то можно попробовать hypothesis-graphql. Библиотека сгенерирует случайные запросы по схеме, в полученные от сервера ответы можно будет проверить на отсутствие ошибок.
Здравствуйте, судя по одному из скриншотов, вы используете Swagger UI и соответственно Open API. Рассматривали ли использование инструментов для автоматического тестирования по Open API схеме? Вроде Schemathesis, Dredd или REST-ler. Если да, то как бы вы сравнили их с Postman?
В Open API 2.0 ключ "example" используется в меньшем количестве мест, по сравнению с 3.0, а именно в schemaObject и fileSchema. Причем для генерации тестов можно использовать только первый. Schemathesis поддерживает "example" только в таких случаях для Open API 2.0, чтобы следовать спецификации.
Но! Поддерживаются расширения "x-example" и "x-examples" для всех мест где определены соответствующие "example" и "examples" из Open API 3.0.
Т.е. это может выглядеть так (я убрал некоторые части для краткости)
Документацию обновлю, действительно там не очень явно эта ситуация описана.
P.S. Для более быстрой обратной связи, возможно будет проще использовать мой телеграм
В целом такое происходит из-за того что когда Hypothesis сталкивается с падением теста, он пытается удостовериться что ошибка надежно воспроизводится. Если у него не получается, то он выводит это сообщение об ошибке.
С учетом встроенных проверок, различающиеся идентификаторы не должны вызывать проблему если они оба соответствуют схеме. Но я думаю, что в целом у вас верное понимание ситуации (особенно об идемпотентности)!
Чаще всего такое поведение связано с тем что внутреннее состояние тестируемого сервиса отличается в начале каждого "теста" (это может быть и последовательность запросов, если рассматривать stateful тестирование). Например, если имена сущностей в сервисе должны быть уникальные, то:
Запрос на создание сущности с именем Test, пришел 201й ответ несоответствующий схеме, но в сервисе сущность успешно создалась. Hypothesis зарегистрировал ошибку.
Hypothesis пытается воспроизвести эту ошибку отправляя такой же запрос как в предыдущем пункте. Получает 409 который уже соответствует схеме - предыдущая ошибка не воспроизводится
БОльшая часть такого рода проблем решается очисткой состояния приложения перед каждым тестом. В CLI это можно сделать при помощи хука before_call, в Python тестах через использования контекстного менеджера в теле теста (как рекомендуется в документации Hypothesis).
В зависимости от сложности тестируемого сервиса, добавление логики для очистки состояния может сильно замедлить тесты, но результаты будет легче воспроизвести.
В данный момент, это логику напрямую не отключить, но я планирую сделать такую возможность (возможно даже включить это по-умолчанию)
Надеюсь, что мой комментарий поможет вам :)
Рад слышать! :) Вам спасибо за новый issue и комменты выше - буду благодарен за предложения и любую обратную связь :)
Спасибо за тексты ошибок. Скорее всего там под капотом тоже используется валидация JSON Schema, только отдается конкретная ошибка из leaf узла где есть
additionalProperties: false. В то время когда в jsonschema отдается ошибка из узла самого близкого к корню (т.е.oneOf). Скорее всего это можно будет решить легче чем я думал изначально, просто выбрав другую ошибку из дерева которое возвращает jsonschema :)В данный момент Schemathesis использует jsonschema для валидации схем и выводит ошибку оттуда напрямую. Я однозначно хочу это улучшить - для этого есть отдельный issue (довольно долго уже висит). Вполне вероятно что будет проще написать валидацию напрямую чем использовать ошибки из jsonschema (которые особенно неприятно разбирать из-за того древовидной структуры ошибок которую эта библиотека отдаёт).
Я постараюсь вернуться к этой проблеме в ближайшее время.
Отдельно хочу сказать что эту валидацию можно отключить (
--validate-schema=false), если нужно запустить тесты без учета валидности схемы.EDIT: Ответ на комментарий выше
На мой предвзятый взгляд - да. С точки зрения поиска дефектов Schemathesis дает намного больше возможностей чем Dredd. В основном за счет использования Property-Based тестирования и генерации данных даже если примеров в схеме нет. Так же Schemathesis полноценно поддерживает Open API 3 (в Dredd поддержка эксперементальная). Конечно, Dredd умеет какие-то вещи которые Schemathesis не умеет. Например поддержка API Blueprint и хуков на разных языках. В FAQ можно почитать немного более развернутое сравнение.
Если говорить о сравнении эффективности на реальных проектах, то можно посмотреть эксперименты одной из статей для ICSE 2022. Сама статья должна быть опубликована в декабре. Эксперименты включают тестирование различных приложений с Open API схемами через Dredd, Schemathesis и еще несколько проектов. Они измеряют покрытие кода в приложениях, ошибки в коде и т.д. Например в одном из экспериментов Schemathesis покрыл 65% кода (в строчках) бэкенда, а Dredd 38%. В некоторых примерах разница меньше, но в целом, в этих экспериментах Schemathesis показал больший или примерно такой же процент покрытия чем Dredd, даже учитывая тот факт, что использовалась довольно старая версия Schemathesis в которой еще не было негативного тестирования.
Спасибо! Рад, что вам понравилась идея! :)
Бесплатная опция обязательно будет :) В том числе и для Open Source проектов.
Рассматривали ли вы использование Hypothesis для генерации данных или других аспектов тестирования (например минимизации найденной ошибки)? В нем есть довольно много разных "стратегий" для генерации данных, включая строки, числа, списки, даты и тому подобное. Кроме этого они легко сочетаются друг с другом и позволяют генерировать практически произвольно сложные структуры данных.
Например, Schemathesis использует этот фреймворк в том числе и для того чтобы генерировать входные данные по Swagger 2.0 / Open API 3.0 / GraphQL схемам (а так же и данные которые не подходят под схемы).
А что вы имеете ввиду под подготовкой тестовых данных? Если именно умение генерировать данные, то кроме вышеупомянутого инструмента, REST-ler и Cats (а так же некоторые другие проекты) тоже умеют генерировать тестовые данные без использования явных примеров из схем. Правда, они их не всегда умеют экспортировать их напрямую, а используют сразу при запуске инструмента.
Могу посоветовать серию статей (за моим авторством) на эту тему - https://dygalo.dev/blog/rust-for-a-pythonista-3/
В последней части там довольно много деталей о том как такие модули собирать, тестировать и дебажить.
FastAPI действительно хорош, но хочу отметить, что в данный момент (версия 0.54.1) он может генерировать схемы которые не являются корректными согласно спецификации Open API версий 3.0.x.
Это происходит из-за того, что
pydantic, используемый в FastAPI для создания JSON схем использует Draft 7, а не Wright Draft 00 (aka Draft 05) указанный в Open API 3.0.x спецификациях.Конкретная проблема заключается в ключевых словах
exclusiveMinimumиexclusiveMaximum, значения которых в JSON Schema Draft 06 стали иметь типnumberи до этого былиboolean. Т.е. если схема от FastAPI включает себя эти ключевые слова, то они будут типаnumber, а неboolean, как должны быть согласно спецификации.В Schemathesis это решается через специальную опцию командной строки
--fixups=all, но по-умолчанию валидация не пропустит такую схему. В Open API 3.1 будет использоваться более новый Draft 2019-09 и конкретно эта проблема должна решиться. На стороне FastAPI так же существует issue посвященный этой проблемеНа данный момент в Schemathesis сгенерированные данные соответствуют схеме (если нет, то стоит завести баг репорт), но возможны ситуации когда приложение может посчитать их невалидными, например из-за дополнительных проверок которые не укладываются в саму схему и реализованы вручную в приложении.
Т.е. то что они расцениваются приложением как невалидные это больше особенность реализации конкретного приложения и его схемы чем намеренное поведение со стороны Schemathesis.
Тем не менее генерация невалидных данных у нас в плане на ближайшие пару месяцев