Доброго времени суток, Хабр.
Сегодня я решил представить вам перевод цикла статей для подготовки к Spring Professional Certification.
Это перевод только первой статьи, если он зайдет аудитории, я продолжу выпуск переводов.
- Часто в них информация не структурирована, не собрана, или не актуальна
- Молодые разработчики могут не знать английский. Этот цикл можно использовать не только для сертификации, но и для самообучения/повторения материалов.
- Этими материалами можно пользоваться при подготовке к собеседованию, т.к. они выстроены в виде вопросов и ответов.
- Важное, и самое главное преимущество — этот QA сделан из вопросов из официального Study Guide от Pivotal.
- Некоторые вопросы, которые казались мне лишними или которых не было в гиде я осознанно упустил.
- Внедрение зависимостей, контейнер, IoC, бины
- AOP (аспектно-ориентированное программирование)
- JDBC, транзакции, JPA, Spring Data
- Spring Boot
- Spring MVC
- Spring Security
- REST
- Тестирование
- Spring 5 Design Patterns
- Spring in Action 4th edition
- Spring Security — Third Edition
- Core Spring 5 Certification in Detail by Ivan Krizsan
- Spring Documentation and Spring API javadocs
И так, начнем.
Внедрение зависимостей — это специальный паттерн, который уменьшает связь между Spring компонентами. Таким образом, при применении DI, ваш код становится чище, проще, его становится легче понять и тестировать.
Согласно паттерну DI, создание объектов для зависимостей переходит на фабрику или отдается третьей стороне. Это означает, что мы можем сосредоточиться на использовании этих объектов вместо их создания.
- Уменьшенная связь между частями приложения
- Улучшенное тестирование
- Улучшенная архитектура приложения
- Уменьшает шаблонный код
- Стандартизирует разработку приложения
- Улучшенное тестирование. В тестах бин может быть заменен специальным объектом(mock или stub), который реализует интерфейс бина.
- Позволяет использовать механизм динамических прокси из JDK(например, при создании репозитория через Spring Data)
- Позволяет скрывать реализацию
В Spring Framework интерфейс org.springframework.factory.BeanFactory предоставляет фабрику для бинов, которая в то же время является IoC контейнером приложения. Управление бинами основано на конфигурации(java или xml).
Интерфейс org.springframework.context.ApplicationContext — это обертка над bean factory, предоставляющая некоторые дополнительные возможности, например AOP, транзакции, безопасность, i18n, и т.п.
Основа Spring Framework — контейнер, и наши объекты "живут" в этом контейнере.
Контейнер обычно создает множество объектов на основе их конфигураций и управляет их жизненным циклом от создания объекта до уничтожения.
Контейнер — это объект, реализующий интерфейс ApplicationContext.
- Контейнер создается при запуске приложения
- Контейнер считывает конфигурационные данные
- Из конфигурационных данных создается описание бинов
- BeanFactoryPostProcessors обрабатывают описание бина
- Контейнер создает бины используя их описание
- Бины инициализируются — значения свойств и зависимости внедряются в бин
- BeanPostProcessor запускают методы обратного вызова(callback methods)
- Приложение запущено и работает
- Инициализируется закрытие приложения
- Контейнер закрывается
- Вызываются callback methods
Spring обеспечивает несколько разновидностей контекста.
Есть несколько основных реализаций интерфейса ApplicationContext:
- FileSystemXmlApplicationContext
- ClassPathXmlApplicationContext
- AnnotationConfigApplicationContext
- XmlWebApplicationContext
- AnnotationConfigWebApplicationContext
Примеры создания контекста:
ApplicationContext ctx = new FileSystemXmlApplicationContext(
"c:/bean_properties.xml");
ApplicationContext ctx = new AnnotationConfigApplicationContext(
"com.springdemoapp.JavaConfig.class");- Загрузка описаний бинов, создание графа зависимостей(между бинами)
- Создание и запуск
BeanFactoryPostProcessors - Создание бинов
- Spring внедряет значения и зависимости в свойства бина
- Если бин реализует метод
setBeanName()из интерфейса NameBeanAware, то ID бина передается в метод - Если бин реализует BeanFactoryAware, то Spring устанавливает ссылку на bean factory через
setBeanFactory()из этого интерфейса. - Если бин реализует интерфейс ApplicationContextAware, то Spring устанавливает ссылку на ApplicationContext через
setApplicationContext(). BeanPostProcessorэто специальный интерфейс(о нем ниже), и Spring позволяет бинам имплементировать этот интерфейс. Реализуя методpostProcessBeforeInitialization(), можно изменить экземпляр бина перед его(бина) инициализацией(установка свойств и т.п.)- Если определены методы обратного вызова, то Spring вызывает их. Например, это метод, аннотированный
@PostConstructили методinitMethodиз аннотации@Bean. - Теперь бин готов к использованию. Его можно получить с помощью метода
ApplicationContext#getBean(). - После того как контекст будет закрыт(метод
close()из ApplicationContext), бин уничтожается. - Если в бине есть метод, аннотированный
@PreDestroy, то перед уничтожением вызовется этот метод. Если бин имплементирует DisposibleBean, то Spring вызовет методdestroy(), чтобы очистить ресурсы или убить процессы в приложении. Если в аннотации@Beanопределен методdestroyMethod, то вызовется и он.
Если вы используете JUnit 5, то вам нужно указать 2 аннотации:
- ```@ExtendWith(TestClass.class)``` — используется для указания тестового класса
- ```@ContextConfoguration(classes = JavaConfig.class)``` — загружает java/xml конфигурацию для создания контекста в тесте
Можно использовать аннотацию @SpringJUnitConfig, которая сочетает обе эти аннотации.
Для теста веб-слоя можно использовать аннотацию @SpringJUnitWebConfig.
Если это не веб-приложение, то есть 2 способа:
- Регистрация shutdown-hook с помощью вызова метода
registerShutdownHook(), он также реализован в классе AbstractApplicationContext. Это предпочтительный способ. - Можно вызвать метод
close()из класса AbstractApplicationContext.
В Spring Boot приложении:
- Spring Boot самостоятельно зарегистрирует shutdown-hook за вас.
Чтобы создать класс с конфигурацией на основе Java-кода, нужно аннотировать его с помощью
@Configuration.
Этот класс будет содержать фабричные методы для создания бинов в контейнере.
Эти методы должны быть аннотированы аннотацией @Bean.
Пример:
@Configuration
public class DSConfig {
@Bean
public DataSource dataSource() {
return DataSourceBuilder
.create()
.username("")
.password("")
.url("")
.driverClassName("")
.build();
}
}Этот класс поместит в контейнер экземпляр класса DataSource. Позднее его можно будет использовать при доступе к базе данных.
Component scanning(сканирование компонентов) — Spring автоматически обнаруживает бины, которые будут находиться в контейнере. Это бины с аннотациями-стереотипами.
Однако сканирование компонентов не включено по умолчанию.
Чтобы включить сканирование, аннотируйте @Configuration-класс аннотацией @ComponentScanning. Spring будет автоматически сканировать тот пакет, в котором находится этот класс и все его подпакеты.
Можно указать и другие пакеты для сканирования, и даже классы:
//сканирует 2 пакета
@Configuration(<i>basePackages</i> = {"soundsystem", "video"})//сканирует класс
@Configuration(<i>basePackageClasses</i> = "MyClass.class")Autowiring(внедрение) — Spring автоматически внедрит зависимости во время сканирования или помещения бина в контейнер.
Для внедрения зависимостей используется аннотация @Autowire.
Стереотипы — это аннотации, обозначающие специальную функциональность.
Все стереотипы включают в себя аннотацию @Component.
| Component | Корневая аннотация, которая помечает класс как кандидат для автовнедрения |
| Controller | Указывает, что класс является контроллером для отправления данных на фронт. |
| @RestController | Указывает, что класс является контроллером для REST. Содержит аннотации Controller и @ResponseBody |
| Service | Указывает, что класс является сервисом для выполнения бизнес-логики |
| Repository | Указывает, что класс является репозиторием для работы с бд |
| @Configuration | Указывает, что класс содержит Java-конфигурацию(@Bean-методы) |
Область видимости — scope, скоуп. Существует 2 области видимости по умолчанию.
| Singleton |
Область видимости по умолчанию. В контейнере находится всего 1 экземпляр бина |
| Prototype |
В контейнере может находится любое количество экземпляров бина |
И 4 области видимости в веб-приложении.
| Request |
Область видимости — 1 HTTP запрос. На каждый запрос создается новый бин |
| Session |
Область видимости — 1 сессия. На каждую сессию создается новый бин |
| Application |
Область видимости — жизненный цикл ServletContext |
| WebSocket |
Область видимости — жизненный цикл WebSocket |
Singleton-бины обычно создаются сразу при сканировании.
Prototype-бины обычно создаются только после запроса.
Чтобы указать способ инициализации, можно использовать аннотацию @Lazy.
Она ставится на @Bean-методы, на @Configuration-классы, или на @Component-классы.
В зависимости от параметра(true или false), который принимает аннотация, инициализация будет или ленивая, или произойдет сразу. По умолчанию(т.е. без указания параметра) используется true.
BeanFactoryPostProcessorработает над описаниями бинов или конфигурационными метаданными перед тем, как бин будет создан.- Spring поставляет несколько полезных реализаций
BeanFactoryPostProcessor, например, читающий property-файлы и получающий из них свойства бинов. - Вы можете написать собственную реализацию BFPP.
Для того чтобы использовать кастомный BFPP. Вы можете переопределить механизм получения данных из метафайлов.
@Bean
public static PropertySourcesPlaceholderConfigurer pspc() {
//создать, сконфигурировать и вернуть pspc
}destroyMethod— указывает на метод обратного вызова. Метод находится в бине.initMethod— указывает на метод обратного вызова. Метод находится в бине.name— имя бина. По умолчанию именем бина является имя метода.value— алиас для name()
Spring использует несколько BeanPostProcessor’ов.
Например, CommonAnnotationPostProcessor или AutowiredAnnotationBeanPostProcessor.
BPP работает с экземплярами бинов, т.е. контейнер создает бин, а затем начинает работать BPP.
Есть 3 варианта для создания таких методов:
@PreDestroyи@PostConstructаннотации- Параметры
initMethodиdestroyMethodв аннотации@Bean, указывающие на методы в классе бина - Переопределенные
InitializingBean#afterPropertiesSet()иDisposableBean#destroy(). Для переопределения этих методов нужно имплементировать соответствующие интерфейсы.
Ниже перечислены типы DI, которые могут быть использованы в вашем приложении:
- Constructor DI
- Setter DI
- Field DI
DI через конструктор считается самым лучшим способом, т.к. для него не надо использовать рефлексию, а также он не имеет недостатков DI через сеттер.
DI через поле не рекомендуется использовать, т.к. для этого применяется рефлексия, снижающая производительность.
DI через конструктор может приводить к циклическим зависимостям. Чтобы этого избежать, можно использовать ленивую инициализацию бинов или DI через сеттер.
- Контейнер определяет тип объекта для внедрения
- Контейнер ищет бины в контексте(он же контейнер), которые соответствуют нужному типу
- Если есть несколько кандидатов, и один из них помечен как
@Primary, то внедряется он - Если используется аннотации
@Autowire+Qualifier, то контейнер будет использовать информацию из@Qualifier, чтобы понять, какой компонент внедрять - В противном случае контейнер попытается внедрить компонент, основываясь на его имени или ID
- Если ни один из способов не сработал, то будет выброшено исключение
Контейнер обрабатывает DI с помощью AutowiredAnnotationBeanPostProcessor. В связи с этим, аннотация не может быть использована ни в одном BeanFactoryPP или BeanPP.
Если внедряемый объект массив, коллекция, или map с дженериком, то Spring внедрит все бины подходящие по типу в этот массив(или другую структуру данных). В случае с map ключом будет имя бина.
//параметр указывает, требуется ли DI
@Authowired(required = true/false)Spring предоставляет аннотацию Qualifier, чтобы преодолеть проблему неоднозначности при DI.
@Bean
@Qualifier("SomeClass1")
public SomeClass getField() {...}
//…
@Autowire
@Qualifier("SomeField1")
public SomeClass someField;Если в контейнере есть несколько бинов одного типа(SomeClass), то контейнер внедрит именно тот бин, над @Bean-методом которого стоит соответствующий квалификатор. Также можно не ставить квалификатор на метод, а использовать имя бина в качестве параметра квалификатора.
Имя бина можно можно указать через параметр аннотации Bean, а по умолчанию это имя фабричного метода.
Прокси это специальный объект, который имеет такие же публичные методы как и бин, но у которого есть дополнительная функциональность.
Два вида прокси:
- JDK-proxy — динамическое прокси. API встроены в JDK. Для него необходим интерфейс
- CGLib proxy — не встроен в JDK. Используется когда интерфейс объекта недоступен
Плюсы прокси-объектов:
- Позволяют добавлять доп. логику — управление транзакциями, безопасность, логирование
- Отделяет некоторый код(логирование и т.п.) от основной логики
Если в контейнере нет экземпляра бина, то вызывается @Bean-метод. Если экземпляр бина есть, то возвращается уже созданный бин.
При использовании Java-конфигурации вы можете использовать аннотацию @Profile.
Она позволяет использовать разные настройки для Spring в зависимости от указанного профиля.
Ее можно ставить на @Configuration и Component классы, а также на Bean методы.
Profile("!test")
//загружать со всеми прифилями, кроме теста@Bean("dataSource")
@Profile("production")
public DataSource jndiDataSource() {...}
@Bean("dataSource")
@Profile("development")
public DataSource standaloneDataSource() {...}Для этого можно использовать аннотацию @Value.
Такие значения можно получать из property файлов, из бинов, и т.п.
@Value("$some.key")
public String stringWithDefaultValue;В эту переменную будет внедрена строка, например из property или из view.
Как обычно, просьба присылать правки или найденные ошибки в личку.
Комментарии (51)
shalomman
06.10.2019 18:06Внедрение зависимостей — это специальный паттерн, который уменьшает связь между Spring компонентами (то есть между различными POJO).
Я не думаю, что Spring компоненты являются POJO. И насколько мне известно, Spring IOC работает только между бинами, иначе говоря нельзя заинжектить что-то в обычный POJO если он не является бином.Anton23 Автор
06.10.2019 18:27Ну, по факту это обычный класс с аннотациями. Я думаю тут написано это для того чтобы показать что бины — это почти обычные классы. Но возможно лучше удалить эту строку.
mad_nazgul
07.10.2019 08:06Любой POJO может быть бином, но не любой POJO является бином.
Можно создать бин из любого POJO класса, потом его передавать (инжектить) в любой бин.
Для того чтобы инжекция была «прозрачной», то рекомендуется делать её через конструктор.
На крайний случай через метод, но никогда не через поле.
TerraV
07.10.2019 17:12Любой неабстрактный класс с конструктором, который Spring может зарезолвить из контекста можно сделать бином. Другое дело что далеко не всегда так поступать можно, равно как не стоит из POJO делать бин. Это антипаттерн. POJO это контейнер данных. Бин это stateful/stateless объект представляющий наружу некоторую функциональность. Какую функциональность может предоставить POJO? Насчет инъекций через конструктор тоже спорное утверждение. Да, так проще мокать в тестах но цена за это — усложнение графа инициализации бинов. И сидеть решать циклическую зависимость может быть очень невесело. На практике инъекции через поля могут быть допустимы, тем более что наружу не будут торчать кишки сеттеров, вообще не относящихся к бизнес-логике бина.
mad_nazgul
09.10.2019 08:43Как минимум бин настроек может быть POJO :-)
Насчет инжекции через поля
1) Нельзя написать unit-test
2) Сильная привязка к контейнеру бинов
Т.о. наша бизнес-логика может быть приколочена к фреймворку который мы используем.
Это как бы моветон.
TerraV
09.10.2019 11:10Не согласен с обоими высказываниями. Начну со второго. Спринг тем и хорош что у него одна реализация, которая одинакова что в разработке что в продакшне. В отличии от JavaEE где как бы есть спецификация а потом ловишь глюки реализации, Спринг везде один. Нет второго фреймворка на который можно мигрировать Спринг-приложение. Не может быть слабой или сильной привязки к Спрингу. Она или есть или ее нет.
Отсюда вытекает контраргумент к первому пункту. Инъекции всегда надо отдавать на откуп Спрингу. Начиная со Spring Boot 2.1 ввели очень правильные ограничения на переопределение бинов и т.п. Сейчас юнит-тесты делаются через @ContextConfiguration/@SpringBootTest (в зависимости от желаемого скоупа) и nested static @TestConfiguration класс. Где внутри определяются реализации бинов на замену. Таким образом прекрасно тестируются классы с инъекцией через поля.
Более того, подобное тестирование покрывает сценарий поднятия версии Spring.mad_nazgul
09.10.2019 11:42+1Я говорил о unit-тестировании.
В большинстве тестов не нужно поднимать какой-либо контекст.
Достаточно задать какие входные данные и что должны получить на выходе.
Поднятие контекста достаточно тяжелая вещь.
А мокирование некоторых бинов не совсем тривиальная задача.
К чему приводит привязка к фреймворку я вижу сейчас.
Когда то было принято решение использовать «стильно-модно-молодежный» jBoss Seam, теперь чтобы «спрыгнуть» лет 5 уже умершего фреймворка, надо будет затратить не понятно сколько времени.
AstarothAst
09.10.2019 11:57Я вообще избавился от тестов со спринговым контекстом, и тестирую свои бины так, словно это обычные классы. Вроде пока все идет хорошо :)
TerraV
09.10.2019 13:13Рано или поздно вы столкнетесь с ситуацией что все тесты зеленые а приложение не стартует (к примеру из-за циклических зависимостей). Или еще хуже, стартует на девелопменте а на продакшене нет (реальный случай между прочим)
mad_nazgul
09.10.2019 14:38Ну интеграционные тесты никто не отменял, они тоже нужны.
Как минимум простой тест на поднятие контекста.
Грубо говоря unit-тестами мы проверяем, что логика(алгоритм) правильный.
И если на входе корректные данные, то на выходе получаем корректные данные.
Плюс можем оттестировать поведение при не корректных данных.
Интеграционные тесты показывают как «кубики» работают в связке.
Скажем так разные инструменты для разных задач.
AstarothAst
09.10.2019 14:40Рано или поздно вы столкнетесь с ситуацией что все тесты зеленые а приложение не стартует (к примеру из-за циклических зависимостей).
Если приложение не стартует из-за циклических зависимостей, то приложение об этом и скажет, и даже граф нарисует — тестирование для этого не нужно. По сути дела каждый запуск приложения будет являться таким тестом, так какой смысл еще и самостоятельно писать эмуляцию этого поведения?
Или еще хуже, стартует на девелопменте а на продакшене нет (реальный случай между прочим)
А какие гарантии тут даст тестирование? Оно только добавит вариантов — на девеломенте и в тестах зеленое, в проде — красное. Или в проде и на девелопменте зеленое, но тесты красные. Тоже реальный случай, если что.
TerraV
09.10.2019 13:07Отлично, только в этом случае вы тестируете не пойми что. Жизненный цикл объекта в JUnit тестах у вас принципиально отличается от того что потом крутится в продакшене. А если еще усугубить это моками то получаются две параллельные вселенные. Если у вас есть бин ну и тестируйте его как бин. Если это не бин (нет никакого Autowiring) то и спорить не о чем.
AstarothAst
09.10.2019 14:42Не соглашусь. Если в ваш бин внедряется некий интерфейс, то никакой параллельной вселенной не будет — вы тестируете поведение своего бина, а не внедренных зависимостей, а ваш бин создался корректно, получив инжект зависимостей в конструктор, с той лишь разницей, что экземпляры этих зависимостей создал не спринг, а макита.
TerraV
09.10.2019 14:50Отлично, в вашем бине есть @PostConstruct. Ваши действия? Эмулировать поведение Спринга? Или @PostConstruct от лукавого и его на равне с @PreDestroy лучше не использовать? И Value аннотации вешать на методы а не на поля. Ну чтоб уж вообще по-хардкору.
AstarothAst
09.10.2019 15:00-1Отлично, в вашем бине есть @PostConstruct. Ваши действия? Эмулировать поведение Спринга?
Вариант дернуть метод помеченный @PostConstruct прямо в ходе теста вами не рассматривается? Это все такой же метод, который можно и нужно протестировать, а не рассчитывать, что Спринг его просто вызовет. Ну, то есть @PostConstruct помогает вам вызвать метод в определенный момент времени, но никак не гарантирует, что он отработает правильно, так что тестировать его все равно придется, а раз так то в чем проблема его вызвать? Разве что эстетические чувства страдают.
на равне с @PreDestroy лучше не использовать?
Ни разу не был нужен — признаюсь, как на духу! В условиях, когда сервис могут снести по kill -9 как-то не пригодился.
И Value аннотации вешать на методы а не на поля
Value аннотации у меня не уходят дальше конфигурации. А в последнее время я от них и вовсе отказался, слишком не гибкий инструмент.TerraV
09.10.2019 15:03То есть вы за эмуляцию жизненного цикла спринга «в меру своего понимания». Ну ок, ваш выбор.
AstarothAst
09.10.2019 15:09-1Вообще-то по-моему очевидно, что я за тестирование своего кода, а не того, как спринг работает.
TerraV
09.10.2019 15:10Вариант дернуть метод помеченный @PostConstruct прямо в ходе теста вами не рассматривается?
Ваше же предложениеAstarothAst
09.10.2019 15:17Это тоже мое предложение:
Это все такой же метод, который можно и нужно протестировать
mad_nazgul
09.10.2019 14:42+2Э-э-э зачем мне тестировать ВСЕ приложение, когда мне нужно протестировать только логику работы какого-то класса/метода?!
Для этого unit-тесты само то.
Понятно, что они не покрывают всей функциональности.
Но их писать легче и они дают определенную уверенность, что при внесении изменений что-то где-то не отвалиться.
Интеграционные тесты это совсем другая история.
Причем в основном грустная, т.к. при любом изменении они будут «падать».
Т.к. тестируется не маленькая часть чего-то, а практически все приложение.TerraV
09.10.2019 14:44А кто писал про ВСЕ приложение? То что можно управлять скопом это новость?
Мы уже вроде договорились что инъекция через конструктор небезопасна из-за циклических зависимостей. Сейчас обсуждаем инъекцию через сеттеры или через переопределение бинов в контексте. Специально для этого есть @TestConfiguration которая конечно несколько противоречива из-за поведения на паблик классах и на нестед статик классах.AstarothAst
09.10.2019 14:52Мы уже вроде договорились что инъекция через конструктор небезопасна из-за циклических зависимостей
Эту «опасность» выявляет первый же запуск приложения — контекст просто не взлетит. Пути решения, вроде, тоже хорошо известны — либо Lazy, либо инжектить как-то иначе. Преимущества работы тестов через Спринг все еще не очевидны.TerraV
09.10.2019 15:02Основное преимущество — стандартизация подхода. Если это бин, тестим через Спринг контекст. Если не бин — создаем вручну. Логика проста и понятна даже джуниору. Этот подход позволяет сократить стоимость владение, когда два внешне одинаковых класса тестируются по-разному. Спринг контекс отработает все постпроцессоры и даст наглядную картину как оно будет выглядеть в продакшене. Если вы создаете бин вручную и вручную же эмулируете жизненный цикл Спринга то у меня для вас плохие новости…
mad_nazgul
09.10.2019 15:11Как раз основная идея бинов в Spring'е было то, что они ничего не знают о Spring'е.
Как минимум, когда вводили конфигурацию на основе xml.
Потом ввели конфигурацию на основе аннотации и граница была стерта. Бины узнали, что есть Spring.
... @Autowired private ApplicationContext applicationContext; ...
Как вершина этого подхода.
Потом сделали конфигурацию на основе классов.
Что позволило опять скрыть от бина существование Spring'а.
TerraV
09.10.2019 15:22В момент когда у вас появляется lifecycle вы уже не можете его игнорировать. Бины в Спринге подчиняются жизненному циклу хотите вы этого или нет. С этого момента у вас по-сути три варианта — 1. писать бин так чтобы жизненный цикл было можно игнорировать (тем самым отказываясь от использования части функциональности спринга), 2. тестировать используя Спринг контекст и делегируя ему нативное управление жизненным циклом либо 3. эмулировать жизненный цикл вручную
mad_nazgul
09.10.2019 15:29-1Э-э-э мухи отдельно, котлеты отдельно. Жизненный цикл бина это игрушки Spring'а и они меня мало интересуют в рамках бизнес-логики.
Основная задача unit-тестов бинов протестировать, что логика в классе правильная.
Сам бин о своем жизненном цикле знать ничего не должен.
Очень желательно, чтобы он и о Spring ничего не знал.
По хорошему, все описание жизненного цикла бина должно быть в кнофигурационном/ых классе/ах.
AstarothAst
09.10.2019 15:14Спасибо за «плохие новости», однако все работает — и с постпроцессорами, и с тестированием через «ручное создание». Можете даже еще один минус поставить, возможно вам станет от этого легче.
Кстати, у меня вопрос — нынче тестовый контекст взлетает, когда собираешь не толстый готовый к деплою джарник, а всего-то библиотеку? Пару лет назад, когда выделял общую логику в отдельный джар этот самый тестовый контекст напрочь отказывался взлетать, то ли нервничал, что @SpringBootApplication найти не мог, то ли еще что… А ведь основная масса постпроцессоров именно туда и ушла. Так я от тестового контекста и отказался.
mad_nazgul
09.10.2019 15:04Можно управлять и скопом.
Например скоуп работы с БД, это уже больше 80% приложения.
Остатки, это на http-контроллеры и интеграции со внешними системами.
А если поднимать веб-контекст — то это просто все приложение.
Насчет «циклических зависимостей».
Так в конструктор инжектится интерфейс.
И если создавать бины типа интерфейса, то Spring их замечательно проксирует и никаких проблем с циклическими зависимостями.TerraV
09.10.2019 15:10Если не секрет то как вы пишете JUnit тесты для БД?
mad_nazgul
09.10.2019 15:16
AstarothAst
09.10.2019 15:18Юнит-тесты — для БД? Простите, а что они должны тестировать???
PqDn
09.10.2019 10:58+1вот ты придумал сложный запрос с кучей джойнами и агрегаторными функциями. Вот такое и желательно затестировать. Так в впринципе можно разработку запроса вести
Ведь рано или поздно в твой код придет Антон, и ченить попробует в запросе поменятьmad_nazgul
09.10.2019 15:30Э-э-э как бы тестирование запросов это не задача unit-тестирования. Это немного другая задача.
Если действительно «сложный запрос», то для его тестирования нужно
1) Соответствующая БД (заменители типа H2 или Derby не подойдут)
2) Соответствующая структура БД (таблицы, ключи, внешние ключи, триггеры, ограничения и пр)
3) Соответствующие данные (Т.к. в зависимости от данных запрос легко может выдавать все что угодно)
Т.о. для тестирования запроса надо
1) Поднять инстанс БД
2) Накатить структуру БД
3) Накатить данные в БД
Чтобы это сделать быстро и безболезненно, скорее всего, нужен Docker.
В котором поднимается БД и на нее накатывается соответствующий дамп.
И уже к БД в докере делается запрос и проверяются результаты.
Вот это все как-то на unit-тест не похоже ни разу. :-)
AstarothAst
09.10.2019 17:38Все так, просто этому не место в юнит-тестах. Это вообще слой БД, так что есть вариант запихнуть это все в хранимую процедуру, а из приложения дергать уже ее. С другой стороны в чем-то я понимаю причины возникновения юнит-тестов, которые тестируют запросы — народ просто не знает где и как их еще писать, сами БД это дело никак не поддерживают и не поощряют, вот и оседает тестирование БД в юниттестах.
AstarothAst
09.10.2019 15:16Насчет «циклических зависимостей».
Так в конструктор инжектится интерфейс.
И если создавать бины типа интерфейса, то Spring их замечательно проксирует и никаких проблем с циклическими зависимостями.
Это либо не так, либо не совсем так — намедни мне удалось создать такую закольцованную структуру. Почесал голову и начал думать, где у меня, собственно, дырка в логике, если получилась такая петля и кто на ком стоял.mad_nazgul
09.10.2019 15:20Вообще странно.
Насколько я учил.
Проблема с циклическая зависимостью может быть, только если инжектяться классы.
Когда работают через инжектиться все через интерфейсы, то в начале создается прокси, потом он разруливает по конкретным реализациям.
Сам недавно на такое натолкнулся.
Вместо интерфейса указал класс.AstarothAst
09.10.2019 15:44Ну, вот набросал, получается.
interface IA { } interface IB { } @Component public class IAImpl implements IA { public IAImpl(@Autowired IB ib) { } }
@Component public class IBImpl implements IB { public IBImpl(@Autowired IA ia) { } }
При запуске выдает:***************************
APPLICATION FAILED TO START
***************************
Description:
The dependencies of some of the beans in the application context form a cycle:
------¬
| IAImpl defined in file [G:\.....\IAImpl.class]
^ v
| IBImpl defined in file [G:\.....\IBImpl.class]
L------
mad_nazgul
09.10.2019 05:47А можно и так
A:
public interface IA { public void testA(); } ... public class IAImpl implements IA { private IB ib; IAImpl(IB ib) { this.ib = ib; } public void testA() { System.out.println("TEST A"); ib.testB(); } }
B:
public interface IB { public void testB(); } public class IBImpl implements IB { private IA ia; IBImpl(IA ia) { this.ia = ia; } public void testB() { Random random = new Random(); if(random.nextBoolean()) { System.out.println("TEST B"); } else { ia.testA(); } } }
А вся «грязь» будет здесь:
@SpringBootApplication public class Main { @Bean public IA iaBean(@Lazy IB ibBean) { return new IAImpl(ibBean); } @Bean public IB ibBean(IA iaBean) { return new IBImpl(iaBean); } @Bean public CommandLineRunner commandLineRunner() { return new CommandLineRunner() { @Autowired private IA ia; @Autowired private IB ib; @Override public void run(String... args) throws Exception { ia.testA(); System.out.println("--------------"); ib.testB(); } }; } public static void main(String[] args) { SpringApplication.run(Main.class, args); } }
Т.о. ни IAImpl не знает о реализации IB, ни наоборот IBImpl не знает о реализации IA. Ни оба вместе не знают об Spring'е.
Все знание о поднятие контекста и разрешения зависимостей находиться в конфигурационном файле. Где проблемы «циклических» зависимостей решаются средствами Spring'аAstarothAst
09.10.2019 09:19Фактически ваше решение — добавление Lazy в конструктор, а оно сработает и в моем примере:
public IAImpl(@Lazy @Autowired IB ib) { }
Выносить это в конфигурацию или нет — вопрос открытый, тут от предпочтений. В данном случае тут по-моему вообще стоит подумать почему возникла кольцевая зависимость? Это ж где-то дырка в логике построения самого приложения, а Lazy просто костыль, который позволяет как-то ехать и не падать на старте.mad_nazgul
09.10.2019 15:23Скажем так. Проблемы поднятия контекста, когда он локализован только в конфигурационных файлах (классы или xml) видны более явно, чем если бы конфигурация была бы размазана тонким слоем по всему приложению.
И тут уже в зависимости от задачи каждый сам решает как решать данную проблему.
Либо меняя имплементацию сервисов. Либо изменяя правила поднятия контекста.
kacetal
07.10.2019 09:21А на сколько ценится такая сертификация не в контексте саморазвития, но у работадателей?
Anton23 Автор
07.10.2019 09:26Однозначно ценится, хоть и не является важным фактором. Некоторые госкомпании требуют сертификаты. Сертификация может сильно помочь при устройстве на работу когда опыта мало или нет совсем. Людям, уже достигшим чего-то в разработке сертификаты не нужны и не помогают (потому что их знания уже выше тех, которые проверяются при сертификации), просто для галочки. Сертификат даёт интервьюеру понять что человек точно знает определенные темы.
PqDn
07.10.2019 13:08в России такой сертификат не ценится (прежде всего из-за того, что нельзя его сдать в России)
если идти в аутсорсинговую компанию, где тебя будут перепродавать другую компанию, то любой сертификат будет в плюс.
По факту при собеседовании если показываешь свои знания, то работодателю глубоко наплевать на твое образование/сертификатыEjikVTumane
09.10.2019 14:23Ну, справедливости ради, — до 2017 года их можно было сдавать в России. Через любого партнера Pearson VUE, коих хватает.
Pearson VUE is no longer delivering exams for Pivotal. Find more information about Pivotal certification.
Last updated 2017-07-13
PqDn
07.10.2019 13:14CGLib proxy — не встроен в JDK. Используется когда интерфейс объекта недоступен
я бы тут добавил, что если в проекте опираться только на такие прокси, то в проекте можно отказаться от использования интерфейсов для спринг бинов. Но это должно быть прям осознаное решение.
Почему для создания Spring beans рекомендуются интерфейсы?
тут анологично бы добавил, что если написать свой бин пост процессор (или при подключении внешней библиотеки), где будет использоваться стандартная прокся jdk, то если инжекция идет на класс, то все нафиг ломается… Решение — перейти на инжекцию по интерфейсу или использовать cglib
Что такое профили? Какие у них причины использования?
Profile("!test") — я бы такой пример добавил, загружать со всеми прифилями, кроме теста
SeApps
Вот прям то что надо. Автору респект