Как стать автором
Обновить

Комментарии 10

Так получилось что уже продолжительное время я не пользуюсь стримами java (перешел на kotlin) и подзабыл api, но вот это место мне не совсем понятно:
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<*> в качестве результата?

Да, отличное замечание. Стандартные методы CrudRepository возвращают Iterable и я решил вернуть его же, хотя причины на это нет — Spring Data JPA может вернуть и Stream, и даже Set. Обновлю статью и код.

Спринговые аннотации — это, конечно же, хорошо, но если хочется тестироваться против реальной БД, то есть замечательная встроенная PostgreSQL:
github.com/zonkyio/embedded-database-spring-test

Она прям в одно косание интегрируется со спринговым проектом, а еще умеет накатывать Flyway миграции.

Ну судя по тому, что я вижу, это просто wrapper для запуска Postgres в рамках тестов + попытка реализовать свой AutoconfigureTestDatabase. В этом, конечно, нет ничего плохого, просто непонятно, какую проблему это решает, которую не решает стандартная тестовая библиотека Spring? И Flyway, и Liquibase @DataJpaTest конфигурирует.


Если уж хочется принести полноценный embedded postgres, я бы скорее порекомендовал TestContainers, там хотя бы будет изолированный сервер, а не просто запускалка локальной базы Postgres.

Тестконтейнеры — это очень замечательно, если ваш CI позволяет запустить это. Порой бывает, что Докер в докере, в докере (и так далее), и Тест контейнеры отпадают, как вариант, из-за сложности интеграции.

Я же ничего не путаю, но 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.

1) Ага, от яндекса — вторая из двух известных
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 надо тестировать на той СУБД, которая используется в системе.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории