Наверное каждый, кто занимался UI тестированием приложений, слышал о Page Object и Page Factory петернах проектирования. И, уж точно, каждый из них знает в чем их преимущество. Но когда дело доходит до API, то тут начинается импровизация. Кто как придумал, кто как смог… кто-то формирует зпосы в файлах, кто-то в классас, а кто-то и в тест методах не брезгует. Ниже я опишу вам как решал этот вопрос я у себя на проекте.
А давайте делать как в Page Object

Ну правда, давйте разделим наши запросы на Resources и Actions по аналогии с Pages и Steps. В Resouces будут находиться статические данные к endpoint’ам, а в Actions мы добавим динамические данные и выполним сам запрос. Статические данные будем хранить в атрибутах Request и Format. Request содержит метод запроса и url к endpoint, а Format определяет формат данных которые будут отправлены или получены. Опишем условный Users ресурс нашего приложения со стандартным набором CRUD операций.

А теперь посмотрим как выглядит Actions для UsersResource

Выглядит просто и локанично, правда? Но пока не понятно, что за тип такой Endpoint. Endpoint – это класс билдер зпроса. У себя на проекте я использую RestSharp, так что Endpoint – это обертка над RestRequest, но всегда можно использовать что-то другое.

Если в голове возник вопрос: “А где же Page Factory для наших Page Objects?”, то овет ниже. Это не PageFactory, это Resource который инициализирует все поля Resource слассов.

Такой подхд позволяет построить простоую в поддержке и использовании структуру проекта. Все изменения происходят в одном месте и нет повторного дублироввания кода. Сам проект можно посмотреть и скачать на моем профиле GitHub.