Добавление отрицательных тестов в мой набор тестов dredd/hook CircleCI (документ API на пасеке). Актуально? Другие инструменты?

Мы используем dredd для тестирования нашего API и используем перехватчики python для успешного отделения документа API, однако dredd использует его от остальной логики тестирования.

Мой вопрос: можно ли включить отрицательные тесты в наш рабочий процесс? если да, то какой будет наиболее эффективный метод/инструмент для этого?

Несколько примеров для иллюстрации:

  1. У нас есть вход, который проверяет ответ 200, когда пользователь вводит правильные учетные данные (имя пользователя, пароль). Но мы также хотим добавить тест на неправильные учетные данные, который также будет выполняться при запуске команды «dredd», для этого нам нужно запустить запрос на вход дважды — один раз для правильных учетных данных и один раз для неправильных.

Проблема: - в настоящее время мы не знаем, как запускать любой запрос более одного раза с разной логикой для каждого выполнения

  1. У нас есть информация о профиле пользователя, которую мы хотим запустить один раз в начале набора тестов (сразу после создания) и один раз после выполнения всех других запросов (добавить измерения, присоединиться/покинуть группу и т. д.).

Проблема: - в настоящее время мы не знаем, как запускать любой запрос более одного раза с разной логикой для каждого выполнения

Вопрос простой, я уверен, что должен быть какой-то способ сделать это, но также было бы полезно знать, ищем ли мы ответ в правильном месте... является ли dredd правильным инструментом для такого рода задач. ?


circleci web-api-testing web-testing dredd apiary
person Shachar R    schedule 27.05.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

API Blueprint поддерживает указание нескольких запросов и ответов (многие ко многим). Следующая структура является допустимым действием API Blueprint:

# POST [/something]

+ Request (application/json)
+ Request (application/xml)
+ Response 200
+ Response 500

+ Request (text/plain)
+ Response 415
+ Response 500

У Дредда есть поддержка для этого, хотя и ограниченная. Вы должны иметь их как пары запрос-ответ:

# POST [/something]

+ Request (application/json)
+ Response 200

+ Request (application/json)
+ Response 500

Если вы создаете документацию из одного и того же API Blueprint, я советую вам разделить ее на два документа. Первый с положительными сценариями, которые нужно протестировать и представить пользователям, а второй с отрицательными, которые нужно просто протестировать. Таким образом, вы все еще можете сохранить свою документацию читабельной.

person Honza Javorek    schedule 28.05.2017