Вопрос от подписчика: «Какая правильная архитектура API тестов»
Раскладывай код не по названию, а по тому, насколько он переиспользуемый
Чем шире используется, тем дальше от теста живёт. Чем уже и специфичнее, тем ближе
1️⃣Пакет api
Тут живёт всё про общение с сервисом по HTTP и больше ничего
К примеру класс OrderApiClient дёргает ручки заказов, AuthApiClient отвечает за авторизацию и токены
Внутри пакета, можно сделать пакет dto, который хранит модели запросов и ответов. Здесь нет проверок и нет бизнес логики, только отправили запрос и вернули ответ
2️⃣Пакет asserts
Переиспользуемые проверки, которые нужны во многих тестах
OrderAssertions проверяет статус заказа и поля ответа, CommonAssertions проверяет код ответа и общую структуру контракта. Эти проверки повторяются из теста в тест, поэтому им тут и место
3️⃣Пакет utils
Совсем общие штуки, не привязанные к продукту
DateUtils для работы с датами, RandomDataUrils для генерации тестовых данных, JsonUtils для парсинга. Такой код спокойно переедет в другой проект без изменений
4️⃣Пакет helpers
Уже про твой проект, но переиспользуемая подготовка
UserHelper создаёт типового тестового пользователя, RequestBuilder собирает стандартный запрос к промежуточному сервису с одинаковой информацией. Они знают про предметную область, но не привязаны к одному тесту
Про твой случай с подготовкой ожидаемых данных
Тут соглашусь с лидом. Когда логика ожидаемого результата завязана на конкретный тест, его тоглы и его алгоритм, ей место в приватных методах этого теста
Вынесешь в общий класс, и он быстро превратится в свалку условий под каждый частный случай
Спроси себя, сколько тестов это используют
Если много и независимо от продукта, это utils. Если много, но про твой проект, это helpers или asserts. Если просто отправка http запроса, это пакет api. Если логика только для одного теста, то приватный метод внутри тестового класса
Не пытайся сразу построить идеальную архитектуру, она вырастет из практики
Разнеси api, steps, asserts, utils и helpers по смыслу, специфичное держи рядом с тестом, а общее выноси наружу, когда видишь, что одно и то же повторяется в трёх местах
Раскладывай код не по названию, а по тому, насколько он переиспользуемый
Чем шире используется, тем дальше от теста живёт. Чем уже и специфичнее, тем ближе
1️⃣Пакет api
Тут живёт всё про общение с сервисом по HTTP и больше ничего
К примеру класс OrderApiClient дёргает ручки заказов, AuthApiClient отвечает за авторизацию и токены
Внутри пакета, можно сделать пакет dto, который хранит модели запросов и ответов. Здесь нет проверок и нет бизнес логики, только отправили запрос и вернули ответ
2️⃣Пакет asserts
Переиспользуемые проверки, которые нужны во многих тестах
OrderAssertions проверяет статус заказа и поля ответа, CommonAssertions проверяет код ответа и общую структуру контракта. Эти проверки повторяются из теста в тест, поэтому им тут и место
3️⃣Пакет utils
Совсем общие штуки, не привязанные к продукту
DateUtils для работы с датами, RandomDataUrils для генерации тестовых данных, JsonUtils для парсинга. Такой код спокойно переедет в другой проект без изменений
4️⃣Пакет helpers
Уже про твой проект, но переиспользуемая подготовка
UserHelper создаёт типового тестового пользователя, RequestBuilder собирает стандартный запрос к промежуточному сервису с одинаковой информацией. Они знают про предметную область, но не привязаны к одному тесту
Про твой случай с подготовкой ожидаемых данных
Тут соглашусь с лидом. Когда логика ожидаемого результата завязана на конкретный тест, его тоглы и его алгоритм, ей место в приватных методах этого теста
Вынесешь в общий класс, и он быстро превратится в свалку условий под каждый частный случай
Спроси себя, сколько тестов это используют
Если много и независимо от продукта, это utils. Если много, но про твой проект, это helpers или asserts. Если просто отправка http запроса, это пакет api. Если логика только для одного теста, то приватный метод внутри тестового класса
Не пытайся сразу построить идеальную архитектуру, она вырастет из практики
Разнеси api, steps, asserts, utils и helpers по смыслу, специфичное держи рядом с тестом, а общее выноси наружу, когда видишь, что одно и то же повторяется в трёх местах