Если надо тестировать поведение одного конкретного бина зачем вообще поднимать контейнер? В чём проблема создавать его в тесте вручную?
И потом, а где тогда хранить mock-бины? В src/test/java не пойдёт, потому что модифицированное поведение нам нужно не в тестах, а в обычном режиме работы приложения.
Именно в src/test/… и хранить, если мы говорим про тесты. А вот для чего нужно модифицированное поведение не в тестах, я слабо себе представляю. Вы прям полностью приложение собираетесь поднимать? Тогда это уже интеграционные тесты, которые лучше вообще в отдельный артефакт выделить.
Справедливости ради, стоит уточнить, что не через EntityManager, а через его конкретную имплементацию Session, если говорить о Hibernate. Вот у неё есть замечательный метод.
// the best
compose(
isLang,
isOpen
)(notifications)
?
Судя по первому куску, функции isLang и isOpen, принимают элемент массива и возвращают какой-то результат, а во втором куске функции соединили в одну и в результирующую функцию передали аргументом массив целиком.
Тут либо должно быть
notifications.filter(compose(
isLang,
isOpen
))
либо compose не просто склеивает несколько функций в одну, но и добавляет неочевидное поведение в результирующую функцию, в данном случае в виде фильтрации элементов переданного аргументом массива.
И ещё, по-моему, не очень хорошая идея перепаковывать LGPL-зависимость в свой fat-jar, потому как одним из условий лицензии является возможность обновления этой библиотеки пользователем, а сделать это без пересборки fat-jar-а вряд ли получится без костылей.
Потому советую подумать над дистрибуцией приложения, раз уж предполагается его распространение через sourceforge.
Однозначно нужна только в одном классе (поэтому private). А отладить ее нужно на разных входных данных.
Вынести в отдельный package-private класс с package-private же методом парсинга/расчёта который обложить тестами. В изначальном приватном методе, используя экземпляр этого класса, вызвать расчёт. Экземпляр можно создавать прямо внутри приватного метода.
Если совсем упарываться, то package-private класс сделать внутренним для исходного.
А вообще приватные методы нужно тестировать посредством тестирования публичных, их использующих.
И вот тут-то всё и сломается, как только нужно будет фильтровать по нескольким полям вложенной сущности. Чтобы понять в чём проблема, достаточно глянуть на запросы, генерируемые такой спекой.
Если надо тестировать поведение одного конкретного бина зачем вообще поднимать контейнер? В чём проблема создавать его в тесте вручную?
Именно в src/test/… и хранить, если мы говорим про тесты. А вот для чего нужно модифицированное поведение не в тестах, я слабо себе представляю. Вы прям полностью приложение собираетесь поднимать? Тогда это уже интеграционные тесты, которые лучше вообще в отдельный артефакт выделить.
Самурай без меча подобен самураю с мечом только без меча. :)
doSomething(int value) {
value = 321;
}
value = 123;
println(value);
doSomething(value);
println(value);
Если значение в функцию doSomething() будет передаваться по ссылке, то вывод будет следующим
123
321
А нужно всего лишь сконфигурировать FlushModeType.
коррелирует с результатом этого
?
Судя по первому куску, функции isLang и isOpen, принимают элемент массива и возвращают какой-то результат, а во втором куске функции соединили в одну и в результирующую функцию передали аргументом массив целиком.
Тут либо должно быть
либо compose не просто склеивает несколько функций в одну, но и добавляет неочевидное поведение в результирующую функцию, в данном случае в виде фильтрации элементов переданного аргументом массива.
Потому советую подумать над дистрибуцией приложения, раз уж предполагается его распространение через sourceforge.
InputStream-ы после воспроизведения не закрываются, что так же не есть хорошо.
Скорость — это, конечно, хорошо, но только до первых разборок, почему пришедший массив бинарных данных не был корректно распознан.
И, да, вызов метода через рефлексию — это низкоуровневый костыль. Иногда удобный, но всё-таки костыль.
Вынести в отдельный package-private класс с package-private же методом парсинга/расчёта который обложить тестами. В изначальном приватном методе, используя экземпляр этого класса, вызвать расчёт. Экземпляр можно создавать прямо внутри приватного метода.
Если совсем упарываться, то package-private класс сделать внутренним для исходного.
А вообще приватные методы нужно тестировать посредством тестирования публичных, их использующих.
Хотя, конечно, каждый решает для себя сам, готов ли он принять такие риски.
И вот тут-то всё и сломается, как только нужно будет фильтровать по нескольким полям вложенной сущности. Чтобы понять в чём проблема, достаточно глянуть на запросы, генерируемые такой спекой.