Энтони Гонсалвес - Изучаем Java EE 7

public class BookServiceIT {

··@Test

··public void shouldCheckNumberIsMOCK () {

····Weld weld = new Weld();

····WeldContainer container = weld.initialize();

····BookService bookService =

container.instance(). select(BookService.class). get();

····Book book = bookService.createBook("H2G2", 12.5f, "Интересная книга

········································на тему высоких технологий");

····assertTrue(book.getNumber(). startsWith("MOCK"));

····weld.shutdown();

··}

}

Интеграционный тест BookServiceIT в листинге 2.54 требует, чтобы был активизирован MockGenerator. Для этого необходимо выделить отдельный файл beans.xml для тестирования (листинг 2.55) и активизации альтернатив (с тегом ). Если вы захотите увеличить объем журналов в тестовой среде, можете активизировать LoggingInterceptor в файле beans.xml.

·······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">

··

····org.agoncal.book.javaee7.chapter02.MockGenerator

··

··

····org.agoncal.book.javaee7.chapter02.LoggingInterceptor

··

Для выполнения интеграционного теста с помощью плагина 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.

В предыдущей главе мы говорили о CDI, контексте и внедрении зависимостей, — центральной общей спецификации, действующей на всей платформе Java EE. Она помогает справляться с регулярно возникающими проблемами, связанными с внедрением, альтернативами, стереотипами, производителями данных. Разработчику приходится постоянно иметь дело с такими концепциями при решении рутинных задач. Еще одна распространенная задача, затрагивающая сразу несколько уровней современных приложений (или даже все уровни), — это валидация информации. Она выполняется повсюду, от уровня представления до базы данных. Поскольку обработка, хранение и получение валидных данных — это важнейшие задачи любого приложения, на каждом уровне правила валидации определяются по-своему. Но иногда на всех уровнях бывает реализована одна и та же логика валидации, из-за чего эта процедура становится длительной, сложной при поддержке, а также чреватой ошибками. Чтобы избежать дублирования правил валидации на каждом из уровней приложения, разработчики часто вплетают логику валидации непосредственно в предметную модель. В результате классы предметной модели оказываются переполнены валидационным кодом, который фактически представляет собой метаданные, описывающие сам класс.