В целом при таких обьемах я бы не парился и оставил похожий подход.
В друг начнете писать тесты активней…
Немного теории: система автотестов для реста, это простая программа. Можно сказать, ты пишешь клиент который использует рест апи (ты же будешь тестировать юзер флоу который повторяет клиентские действия).
Отличие от веб клиента или мобилочки - цель.
Реальный клиент будет рисовать UI для клиента, ты в тестах будешь просто проверять результаты после действия.
Исходя из этого, советую сразу писать тесты как полноценную программу, со всеми артефактами.
Также твоя система должна в какой то степени быть зеркальным отображением бекенда.
Чаще на бекенде есть контроллеры, модель и логика.
Желательно что бы у тебя появилось что то подобное - клиент который будет общаться по хттп, модель\дто для работы с объектами и валидаторы.
Ближе к практике.
Структура проекта:
- Хттп клиент.
а) Если самописный, то его выносят на самый низкий уровень. Хттп клиент умеет удобно делать запросы не зная ничего об твоем приложении.
Сетать нужный метод, хидеры и все что надо для построения запроса. Чаще имеет методы гет, пост … ну и все что надо для общения с рестом. Также например логирование запроса и ответа.
б) Готовый фреймворк\библиотека. Ты используешь готовый фреймворк, ничего плохого не вижу в принципе (сам правда не использую).
Я бы его все равно обвернул как то, что бы в одном месте можно было управлять его настройками. Например снова таки включать выключать логирование
- Клиенты твоего приложения. Это классы \ прослойка, которая знает как общаться с твоим конкретно приложением. Знает пути, хидеры, и боди для выполнения конкретного запроса.
Тут разные подходы можно использовать. Чаще для полноценных тестов я строю 2 запроса на каждый енд поинт:
a) универсальный метод. Он как входящие параметры принимает все необходимые данные и статус код. Выполняет запрос, сравниваем статус код с переданным и возвращает обьект ответ.
Данный метод используем для негативных или специфических тестов.
б) метод для позитивных сценариев. Использует универсальный внутри, всегда передает позитивный статус код. На выходе трансформирует ответ в конкретную модель и дальше возвращает данную модель.
В какой то момент методов станет много, сразу разбивай методы по разным клиентам. Например юзер апи клиент, корзина апи клиент и так далее.
Например енд поинт регистрации клиента. Мы вначале хотим создать тесты конкретно на тестирование регистрации клиента. Будем использовать метод для позитивных тестов для положительных сценариев,
на выходе проверять свойства вернувшигося клиента. Негативный метод будем вызывать с предположительным отрицательным статус кодом и будем смотреть наличие правильного еррор текста в ответе-боди.
Иногда надо проверить и хидеры, у нас есть такая возможность.
Далее метод для позитивных сценариев будет использоваться в других типов тестов - например обновление клиента. Для того что бы проверить обновление - надо вначале зарегистрировать клиента.
Метод для позитивных флоу хорошо подойдет для данных целей.
Трансформаторы JSON/XML в модель могут быть самописными и зависят от языка. У меня в тайпскрипт один метод - jsonToObjectConverter(response: string, objectType: Type) Он умеет проходить по json считывать все его ключи и мапить на модель.
В зависимости от цели и типов тестов - входящими параметрами например для регистрации клиента может быть конкретно модель Customer а для негативных в универсальном методе стринга. Таким образом негативные сценарии, на подобие битый json или просто не валидный формат боди, можно легко проиграть. Для позитивных сценариев модель клиента будет трансформироваться в нужный json и отправлять на сервер (на тайпскрипт ето оч легко - есть функция JSON.stringlify() который на выходе из модели вернет json)
- Степы. Если многие тесты повторяют внутри одни и теже вызовы - создаем степы. Например регистрация клиента может состоять из 3-4 апи вызовов. Выносим это все в один метод. Степы в себе могут использовать вызовы нескольких клиентских
методов.
- Валидаторы ответов\модели. Тут несколько методов. Можно положить где то описание джсона и потом проверять каждый ответ. А можно написать самописные валидаторы, которые будут внутри ассертить нужные поля в ответе. Например Customer.validate(customer: Customer) будет проходиться по свойствам обьекта и проверять динамические проверки. Например : свойство присутствует, длина не меньше 1 символа, если ето год рождения - то цифра больше 1555 года. Это нужно что бы в тестах не было очень много ассертов. Также переиспользывание.
- Подключение к базе данных приложения. Если есть возможность - очень советовал бы выделить место для работы с базой. Очень упрощает создание прекондишинов или проверок созданных данных.
- Лог ридер. У меня была очень хорошая практика вычитки данных из логов прямо в тесте и проверки нужной мне информации.
- Имейл коннектор. Тут много разных вариантов. Можно попросить девелоперов ложить все имейлы где то рядом с сервером или использовать реальные имейлы.
- Репортинг. Я б сказал маст хев тест, запросы ответы и ассерт текст если упал тест. Можно репорты обвернуть в что то красивое, например аллюр, но по желанию и необходимости. Чаще это оверхед в апи тестах.
- Тесты. Тесты состоят из степов и\или вызовов клиентских методов. Все позитивные кейсы флоу работают с моделью. Негативные с ответом (если унифицированны еррор меседжи в приложении, можно тоже конечно на модель положить)
Немного теории про тесты:
a) Динамичность. Круто когда тест очень независим от окружения. Тест сам создает себе прикондишн, выполняет действия и затем подчищает за собой если надо.
б) Атомарность. Тесты маленькие и проверяют конкретно какое то действие или флоу. Я часто разбиваю тесты на несколько категорий: конкретно для енд поинта, конкретный юзер флоу или конкретная фича.
в) Стабильность.
г) Быстрота (я бы сразу закладывал паралелизацию в тесты - для меня это маст…)
Еще немного теории.
Запускать тесты стоит чем раньше тем лучше. У нас сейчас тесты запускаются на этапе создан пулл риквест например. Дает возможность раньше предотвратить появление неисправностей в главных бранчах.
Девелоперы должны использовать тесты. Запустить локально вместо использования постмана или еще каких то тулов - очень ускоряет работу. Сценарии можно проигрывать много раз. По этому тесты должны быть независимы от окружения.
Еще - подобная структура позволит продолжить апи тесты юайными. Так как очень часто в юайных тестых стоит использовать апишные запросы для проверок или создание прикондишина.
Подобную схему обыграл на нескольких системах с использованием разных языков программирования. На текущем последнем проекте 1180 тестов которые выполняются 20 - 23 минуты.
Удачи в написании твоей программы!
Спрашивай если есть вопросы.
(Сорри за орфографические ошибки)
testomat.io управление авто тестами
