Во многом согласен. Здесь @SpringBootTest используется скорее как "сахар". Сейчас на проекте, который послужил источником для данной статьи мы эту аннотацию не применяем. В основном для целей тестирования работы с БД берем либо @JdbcTest и аналоги, либо тестовую конфигурацию с ручным конфигурированием DataSource (постепенно идем к последнему варианту).
Цель таких тестов для нас - это проверка работы именно с БД. В них нет тестирования всей логики, т.е. мы проверяем, что наши запросы работают именно так, как мы и хотим и именно на такой БД, которая будет на проде.
При локальном тестировании нам много времени экономит Gradle. У нас большое количество модулей небольшого размера, и изменения кода в модуле приводят только к его пересборке. А вот при сборке на CI собирается все с нуля.
Можете поподробнее рассказать о вашем процессе тестирования как "черного ящика"? Я правильно понимаю, что это тестирование у вас проходит при сборке на CI? Или это какой-то отдельный этап?
@RequestMapping("/useful")
@RestController
public interface UsefulDataHandler {
SomeData getSomeData();
}
На основе этого интерфейса смежная система генерировала свою реализацию, которая под капотом обращалась к нашему контроллеру. Т.е. в этой системе чтобы получить SomeData нужно было просто вызвать метод.
public UsefulDataHandlerImpl implements UsefulDataHandler {
SomeData getSomeData() {
//do http request and return response
}
}
Теперь представим, что мы добавляем еще один метод:
И здесь мы получаем ситуацию о которой я и писал. Мы должны по разному обрабатывать запросы.
На самом деле рассматривались и другие варианты решения, например, просто назначение методов на разные URL или через фильтры или через заголовки. Самое смешное, что пока никак не сделали.
К тому же статья не претендует на руководство как надо делать. Я столкнулся с копанием во внутренностях Spring, и этот опыт я посчитал интересным чтобы им поделиться.
Во многом согласен. Здесь
@SpringBootTestиспользуется скорее как "сахар". Сейчас на проекте, который послужил источником для данной статьи мы эту аннотацию не применяем. В основном для целей тестирования работы с БД берем либо@JdbcTestи аналоги, либо тестовую конфигурацию с ручным конфигурированием DataSource (постепенно идем к последнему варианту).Цель таких тестов для нас - это проверка работы именно с БД. В них нет тестирования всей логики, т.е. мы проверяем, что наши запросы работают именно так, как мы и хотим и именно на такой БД, которая будет на проде.
При локальном тестировании нам много времени экономит Gradle. У нас большое количество модулей небольшого размера, и изменения кода в модуле приводят только к его пересборке. А вот при сборке на CI собирается все с нуля.
Можете поподробнее рассказать о вашем процессе тестирования как "черного ящика"? Я правильно понимаю, что это тестирование у вас проходит при сборке на CI? Или это какой-то отдельный этап?
Промахнулся с ответом - перенес комментарий
Такой вариант тоже рассматривался, как я написал ниже.
Опишу чуть подробнее ситуацию.
Был интерфейс контроллера
На основе этого интерфейса смежная система генерировала свою реализацию, которая под капотом обращалась к нашему контроллеру. Т.е. в этой системе чтобы получить SomeData нужно было просто вызвать метод.
Теперь представим, что мы добавляем еще один метод:
И здесь мы получаем ситуацию о которой я и писал. Мы должны по разному обрабатывать запросы.
На самом деле рассматривались и другие варианты решения, например, просто назначение методов на разные URL или через фильтры или через заголовки. Самое смешное, что пока никак не сделали.
К тому же статья не претендует на руководство как надо делать. Я столкнулся с копанием во внутренностях Spring, и этот опыт я посчитал интересным чтобы им поделиться.