Comments 10
Spliterator<CakeEntity> cakes = this.cakeRepository.findAll().spliterator();
return StreamSupport.stream(cakes, false)
.map(cakeEntity -> new Cake(...))
.collect(Collectors.toSet());
Для чего через spliterator? Разве нельзя сразу findAll().stream().map()...?
+Могу путать но разве в SpringDataRepository не появилась поддержка Stream<*> в качестве результата?
github.com/zonkyio/embedded-database-spring-test
Она прям в одно косание интегрируется со спринговым проектом, а еще умеет накатывать Flyway миграции.
Ну судя по тому, что я вижу, это просто wrapper для запуска Postgres в рамках тестов + попытка реализовать свой AutoconfigureTestDatabase. В этом, конечно, нет ничего плохого, просто непонятно, какую проблему это решает, которую не решает стандартная тестовая библиотека Spring? И Flyway, и Liquibase @DataJpaTest конфигурирует.
Если уж хочется принести полноценный embedded postgres, я бы скорее порекомендовал TestContainers, там хотя бы будет изолированный сервер, а не просто запускалка локальной базы Postgres.
Я же ничего не путаю, но Spring сам по себе не запустит embedded postgresql? То есть, это будет просто какая-то in-memory БД, в которой детали реализации будут отличатся от PG?
Не запустит, но и не должен, это не его обязанность. Вообще немного лукаво называть embedded-database-spring-test embedded — это самый обычный сервер Postgres (точнее, некий lightweight bundles of PostgreSQL binaries with reduced size), библиотека его просто запускает. Почему бы тогда не иметь локальный сервер Postgres и в нем создавать тестовую базу — не совсем понятно. Ну и если уж совсем-совсем надо запустить Postgres и TestContainers не подходят, то лучше использовать проверенные и поддерживаемые библиотеки, вроде https://github.com/yandex-qatools/postgresql-embedded.
2) Уточню — моя ссылка — это просто обёртка над github.com/opentable/otj-pg-embedded — одни из двух известных решений
3) Почему не использовать локальную БД — такое решение плохо живёт в CI, где надо запускать «здесь и сейчас», без пробрасываняи базы данных в нужный контейнер.
Почему бы тогда не иметь локальный сервер Postgres и в нем создавать тестовую базу — не совсем понятно.
Удобно для CI, можн удобно для разработки, потому что postgresql локально можно и не ставить, удобно потому, что не надо чистить базу между запусками тестов, то есть решает дилемму с аннотацией Transctional
Ну судя по тому, что я вижу, это просто wrapper для запуска Postgres в рамках тестов + попытка реализовать свой AutoconfigureTestDatabase.
Эта штука скачивает дистрибутив postgresql, разворачивает и создаёт базу с нуля. А не использует уже существующий экземляр постгреса.
В этом, конечно, нет ничего плохого, просто непонятно, какую проблему это решает, которую не решает стандартная тестовая библиотека Spring?
Проблему тестирования системы в связке с живой СУБД Postgresql вместо in memory баз. Зачастую то, что работает с абстрактной базой — не будет работать с конкретной. Или наоборот.
И Flyway, и Liquibase @DataJpaTest конфигурирует.
Liquibase надо тестировать на той СУБД, которая используется в системе.
TDD приложений на Spring Boot: работа с базой данных