container.instance(). select(BookService.class). get();
····Book book = bookService.createBook("H2G2", 12.5f, "Интересная книга
········································на тему высоких технологий");
····assertTrue(book.getNumber(). startsWith("MOCK"));
····weld.shutdown();
··}
}
Активизация альтернатив и перехватчиков в файлах beans.xml для интеграционного тестирования
Интеграционный тест BookServiceIT в листинге 2.54 требует, чтобы был активизирован MockGenerator. Для этого необходимо выделить отдельный файл beans.xml для тестирования (листинг 2.55) и активизации альтернатив (с тегом <alternatives>). Если вы захотите увеличить объем журналов в тестовой среде, можете активизировать LoggingInterceptor в файле beans.xml.
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
·······xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance"
·······xsi: schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
·······http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
·······version="1.1" bean-discovery-mode="all">
··<alternatives>
····<class>org.agoncal.book.javaee7.chapter02.MockGenerator</class>
··</alternatives>
··<interceptors>
····<class>org.agoncal.book.javaee7.chapter02.LoggingInterceptor</class>
··</interceptors>
</beans>
Запуск интеграционного теста
Для выполнения интеграционного теста с помощью плагина Maven Failsafe (определенного в pom.xml в листинге 2.53) введите следующую команду Maven:
$ mvn integration-test
Класс BookServiceIT должен выполнить один успешный интеграционный тест. Вы также увидите несколько протоколов или регистраций входа в метод и выхода из него.
Резюме
Из этой главы вы узнали о различиях между объектом POJO, управляемым компонентом и компонентом CDI, а также о том, какие сервисы необходимо применять с каждой компонентной моделью. Благодаря спецификациям Managed Bean (запрос JSR 330) и CDI Bean (запрос JSR 299) в Java EE появилась стандартная, портируемая и типобезопасная поддержка для внедрения зависимостей. CDI предлагает дополнительные возможности, такие как области видимости и контексты, а также расширенные перехватчики, декораторы и события. В действительности CDI напрямую реализует несколько шаблонов проектирования, например «Мост» (с альтернативами), «Наблюдатель» (с событиями), «Декоратор», «Фабрика» (с производителями), и, конечно же, перехват и внедрение.
Перехватчики — это механизм Java EE, имеющий много общего с аспектно-ориентированным программированием, который позволяет контейнеру вызывать сквозные функции вашего приложения. Перехватчики легкие в использовании, мощные и могут быть сцеплены вместе либо расположены в приоритетном порядке для того, чтобы применить к вашему компоненту различную функциональность.
Будучи вертикальной спецификацией, CDI используется в других спецификациях Java EE. На самом деле в следующих главах этой книги так или иначе будут задействованы некоторые сервисы CDI.
Глава 3. Валидация компонентов
В предыдущей главе мы говорили о CDI, контексте и внедрении зависимостей, — центральной общей спецификации, действующей на всей платформе Java EE. Она помогает справляться с регулярно возникающими проблемами, связанными с внедрением, альтернативами, стереотипами, производителями данных. Разработчику приходится постоянно иметь дело с такими концепциями при решении рутинных задач. Еще одна распространенная задача, затрагивающая сразу несколько уровней современных приложений (или даже все уровни), — это валидация информации. Она выполняется повсюду, от уровня представления до базы данных. Поскольку обработка, хранение и получение валидных данных — это важнейшие задачи любого приложения, на каждом уровне правила валидации определяются по-своему. Но иногда на всех уровнях бывает реализована одна и та же логика валидации, из-за чего эта процедура становится длительной, сложной при поддержке, а также чреватой ошибками. Чтобы избежать дублирования правил валидации на каждом из уровней приложения, разработчики часто вплетают логику валидации непосредственно в предметную модель. В результате классы предметной модели оказываются переполнены валидационным кодом, который фактически представляет собой метаданные, описывающие сам класс.
Валидация компонентов решает проблему дублирования кода и излишнего запутывания классов предметной модели. Разработчику достаточно написать ограничение всего один раз, использовать его и валидировать на любом уровне. Валидация компонентов позволяет реализовать ограничение в обычном коде Java, а потом определить его с помощью аннотации (метаданных). Затем вы можете использовать эту аннотацию в своем компоненте, свойствах, конструкторах, параметрах методов и с возвращаемым значением. Валидация компонентов предоставляет простой API, позволяющий разработчикам писать и переиспользовать ограничения, связанные с бизнес-логикой.