видимо pymongo

Попробуй несколько и подумой

Коллеги, ткните пожалуйста куда нибудь, где есть пример тест-дизайна для API
Я устал читать статьи, которые начинаются "ну вот у вас есть требования, вот их и проверяйте" или "вот у вас есть схема, вот ее и проверяйте". Как выполнять тест дизайн сами кейсов на подобном уровне?

Что есть:
клиент-сервер. Сервер имеет RESTfull API, практически без обработчиков. Все входные данные контролируются с фронта.
Я написал отдельный CLI клиент к серверу. Написал тестовую логику для бизнес логики. К примеру, создание сущности через API. Настоло время выполнять тест-дизайн. А как его выполнять на этом уровне?

Что приходит в голову:
-создадим с корректными данными
-создадим с пустым именем
-создадим с пробелами
и прочее

Верно ли размышляю?

Да вы тестировщик

- проверяешь по очереди отсутствие каждого из required параметров запроса
- проверяешь авторизованность разных пользователей на это действие
- проверяешь минимально валидный запрос с корректными required параметрами
- проверяешь  запрос с required параметрами когда какой-то из параметров не проходит проверку по ограничениям
- делаешь так для каждого из required параметров.
- берёшь валидные required параметры, тестируешь поведение optional параметров в запросе

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

Это можно распространить на тело запроса?
Параметров в запросах нет(точнее преобладающее большинство без параметров), только json

Ну если структура Джейсона с его содержимым как-то влияет на результат ответа сервера, то конечно

Ну ещё не понятно как тебе сервер отвечает. Вдруг у вас там на все запросы 200 возвращается, и только текст ответа разный

Но это уже к вопросу что ты будешь проверять после. К тест дизайну тестовых данных это отношения не имеет

Сервер предоставляет только ресурсы и АПИ для управления ими
Таким образом у меня большинство однотипных запросов из разряда "отправил post с json, получил ответ".
Ответ сервера унифицирован и зависит от ресурса, это все уже обязано jsonschema

Так и в чем проблема? Что в питоне не получается проверить? Это чат по реализации логики на питоне все же, не по теории тест дизайна

Так вот же доклад от Ивана Катунова по тест-дизайну, если выписывать тезисы за ним, то получится почти то же самое, что и Евгений ответил:
https://www.youtube.com/watch?v=VTVx5Rx6rsY - часть 1
https://www.youtube.com/watch?v=Tq2thhEiQJE - часть 2

привет всем, можете подсказать, есть массив, в нем должно быть известное мне значение, моя задача перебрать массив чтобы удостоверится,что значение находится в нем

почитать главу о циклах

Или открыть для себя Any.

in

in конечно