Вопрос в том, что вы хотите проверить.Как вы думаете, что сломается на самом верхнем api-слое (то есть слое, получающем HTTP-запрос)?
Обычно написание юнит-теста restful-api звучит немного похоже на оксюморон;) По определению юнит-тесты гораздо меньше, чем использование точки входа HTTP в базу данных.Более того, ваш вопрос основан на том, как написать большие тесты (или приемочные, сквозные тесты).
Остерегайтесь того, что реализация таких крупных тестов (сквозных тестов) требуетусилие:
- Тесты, как правило, намного медленнее
- Расходы на обслуживание тестов, потому что тесты сложнее понять (из-за всех этих зависимостей + настройки тестовых данных)
- они более склонны вызывать ложноположительные тесты (тест показывает «красный», хотя он должен быть «зеленым»).Причина снова в том, что в ваших тестах задействовано больше зависимостей, более вероятна хрупкость.
В моем опыте главное - разнообразие гранулярности теста, поэтому я смешиваю / комбинирую подходы:
- юнит-тестирование для API-интерфейсов (например, несколько более сложных требований к отображению), аутентификация, сложные правила проверки, сложная логика if / else, ...)
- выполнение дымовых тестов на более грубом уровне, HTTP-клиент взаимодействует с API, то есть тестирует интеграцию.Эти тесты покажут мне: сервер может запускаться, основные сценарии использования API работают.В качестве инструмента я рекомендую soap-ui .
- относительно состояния базы данных: я часто начинаю с большинства базовых данных (например, существующих api-пользователей или предварительно определенных неизменяемых тестовых данных).Данные теста для каждого теста должны быть изолированы.Если мой тест включает более сложный поток (например, весь сценарий использования распределен по нескольким HTTP-вызовам), тестовые данные могут зависеть от шагов теста (т. Е. Call-2 может зависеть от состояния сервера, которое было изменено вызовом1)
Может быть, вы можете дать больше информации о конкретном сценарии использования, который вы хотите протестировать, так что можете дать больше помощи?