Слушай, а у нас в проекте мигратор является отдельным приложением. А бекенд не знает про схему бд ничего, только JPA сущности. Правильно же, что в тестах держать актуальную версию миграции бд нужно тогда, чтобы функциональные тесты выполнять (в идеале)?

Не очень понял про “актуальную версию миграции бд”, но по сути тогда достаточно чтобы тесты могли дергать это приложение, чтобы оно управляло бд когда надо.

У меня мигратор просто в функциональных тестах запущен. Разница не большая.

Я имел в виду актуальную схему бд. Спасибо!

С MockMvc по дефолту вообще http-сервер не поднимается в спринге (если не указать webEnvironment в аннотации).

Вообще, это довольно странное решение и вызывает много вопросов. Код выглядит так, будто бы тестирует HTTP-запрос, а по факту тестирует частично десериализацию запроса, частично контроллер, частично сериализацию ответа.

Из-за того, что не поднимается http-сервер, не работают, в частности, резолвинг эксепшенов через forward на /error, что по дефолту используется в Spring-Boot для сериализации ответа в случае возникновения любого exception. Вместо этого просто выбросится эксепшен, который выбрасывается из контроллера. Так что для проверки контракта http api MockMvc плохо подходит в таком виде.

С WebEnvironment.RANDOM_PORT - совсем другое дело. Поднимается полноценный http-сервер и можно тестировать контракт, включая ответы при ошибках. Такие тесты, конечно, выполняются дольше и т.д., но они все равно обычно нужны. А когда они уже есть, то писать еще дополнительные MockMvc тесты без WebEnvironment.RANDOM_PORT выглядит, как оверкил. По сути, единственной их целью в таком случае будет: проверить логику контроллера, замокав различные варианты действий сервис-слоя. Но, как правило, даже если в контроллере есть какая-то логика, она всегда влияет на http-ответ. Так что эти сценарии все равно покроются "настоящими" тестами с WebEnvironment.RANDOM_PORT.

А есть у этой проблемы какое-то название, когда ентити используют вместо ДТО?

г̶о̶в̶н̶о̶к̶о̶д̶  SRP violation :)

Спасибо

Но srp, по-моему, более широкое понятие. Если использовать ентити на веб-слое, то будут проблемы  с транзакционностью.

С чего бы?

SRP более широкое понятие, да. Но более конкретного термина для "использовать энтити в качестве ДТО" я не знаю. Может оно и есть.

https://technology.amis.nl/2020/04/10/spring-blocking-vs-non-blocking-r2dbc-vs-jdbc-and-webflux-vs-web-mvc/

Более менее реалистичные данные

Спасибо, хорошая статья

добрался до компа. если интересно, у меня тут есть доклад, в описании ссылки на преентацию и репо, в моем профиле на gh есть обновленное репо на бут 2.2 с более свежим r2dbc https://www.youtube.com/watch?v=VPGPS3tr9sI&list=PLdrwdvUIjI0oD9lMIbQAwD9aYTxfL-C0p&index=2

спасибо большое!

информативно, спасибо!
только несколько вопросов, раз ты уже вник и хорошо все понимаешь :)
1. рассматривал ли @Async, как такие функции себя ведут при при блокирующем вызове? в чем разница?
2. рассматривал ли вариант где котроллер возвращает CompletableFuture, томкат может принимать обещание потом их обрабатывать, не та же асинхронность?
3. я правильно понимаю? если мы используем котурины с томкат, для какой асинхронной работы, не важно, то корутины используют пул потоков томката(которых 200 по умолчанию) или создают свой независимый пул потоков?

1. В плане производительности большой разницы не будет. Ну разгрузишь ты пул потоков mvc, системе то этого не легче, concurrency не увеличится
2. Нет, смотри пункт 1
3. У корутин будет свой пул, но смысла не много. Суть будет примерно так же, как пример mvc+r2dbc из статьи

Посмотри этот доклад, твои вопросы отпадут https://youtu.be/tjp8pTOyiWg

Народ, а стоит ли читать Spring in action 5 издание? На Амазоне рейтинг обвалили и в комментах нелестно отзываются

Стоит пойти на spring.io в раздел документации, там все топ