Java EE7 и Maven проект для новичков — часть 6

Возобновление из предыдущих частей

Часть № 1 , Часть № 2 , Часть № 3 , Часть № 4 , Часть № 5

В предыдущем посте (часть 5) мы выяснили, как мы можем проводить модульное тестирование, используя Arquillian, наши EJB-сервисы, развертывая их в «реальном» экземпляре сервера приложений Wildfly8.1 . Расширяя предыдущий пример, мы добавим еще немного конфигурации и кода, чтобы мы могли добавлять модульные тесты, в которых участвуют наши объекты JPA2 . Создание, сохранение и извлечение информации из базы данных является очень фундаментальной задачей любого приложения JavaEE. Нам нужно убедиться, что наша модель предметной области и логика, закодированная поверх нее, максимально протестированы. Я собираюсь использовать « простейшую » форму конфигурации и связанных библиотек. Поскольку мы уже тестировали в Wildfly 8.1, мы будем использовать внутреннюю базу данных H2 в памяти, которая связана с сервером, и связанный источник данных ExampleDS .

Обратите внимание , это только для тестирования и демонстрации, в реальной жизни вы захотите тестировать в СУБД, основанной на тяжелом производстве, с той разницей, что вам следует:

• создать тестовую схему БД на вашем сервере БД (например, Oracle, MySQL, DB2…)
• Добавьте соответствующую конфигурацию источника данных на сервер приложений, чтобы он подключался к указанному выше серверу БД.

Мы уже настроили Arquillian и уже используем возможности автономного сервера приложений Wildfly 8.1. В предыдущем посте (часть 5) мы были простым EJB без сохранения состояния, который не извлекал и не сохранял информацию в базе данных. В модуле образца домена мы уже определили простой объектный компонент JPA2. Мы хотели бы протестировать некоторые базовые вещи, такие как сохранение сущности в базе данных, извлечение сущности и т. Д. Для многих проектов даже в наши дни часто используется создание сессионных компонентов без сохранения состояния, которые фактически реализуют этот код для каждой сущности. Возможно, вы слышали о них как о классах «DAO». В нашем случае реализация DAO отсутствует, но применяются те же принципы.

Определение test-persistence.xml

Поскольку мы уже определили стандартный файл persistence.xml в модуле sample-domain (jar), который фактически настраивает наш Entity Manager, нам нужна аналогичная конфигурация. В конце концов очень похожий файл xl персистентности, но на этот раз будет помещен в папку / src / test / resources , потому что он собирается для нас, Entity Manager, который будет выбран во время наших тестов, из нашего Arquillian / Тестовая комбинация Wildfly.

Вот как это выглядит:

Некоторые примечания к вышеуказанному файлу:

• Мы определяем SourceDatasource, который предварительно настроен на Wildly 8.1
• WildFly 8.1 поставляется в комплекте с Hibernate 4.x, поэтому мы используем «безопасные» свойства конфигурации Hibernate.
• Мы используем стратегию ‘ create-drop ‘, так что каждый раз, когда мы запускаем тест (ы), hibernate собирается отбрасывать таблицы в базовой базе данных и воссоздавать их. Это поможет нам в тех случаях, когда мы экспериментируем и постоянно меняем модель предметной области.
• Набережная База данных, которую предлагает Wildly, — H2 , поэтому мы настраиваем Hibernate на использование этого « диалекта ».

Создание теста Arquillian

Вот как выглядит наш тест (вы можете проверить источник по ссылке на git в конце поста):

Некоторые примечания к приведенному выше коду:

Точка 0 : это одна из самых важных частей каждого теста, основанного на Аркиллиане. Здесь мы создаем «войну» в памяти, нашу возможность развертывания, которая будет содержать тестируемые классы и любые другие ресурсы, необходимые для вспомогательных сред. Вся проводка выполняется с использованием основанного на Arquillian фреймворка под названием ShrinkWrap . В нашем случае метод ‘ createDeployment ‘ упаковывает нашу единственную сущность JPA с именем ‘User’ и файл persistence.xml , который на самом деле является test-persistence.xml, в наших ресурсах тестирования, настраивая Entity Manager, который работает по умолчанию Дико источник данных.

Пункт 1: Это специальная аннотация, которая очень удобна для более сложных тестов. Используя эту аннотацию, мы фактически внедряем поддержку JTA (транзакционной) по умолчанию в наших тестовых методах, в этом конкретном тесте не используется интенсивно. Запомните настройку ROLLBACK. Это указывает на то, что независимо от того, что этот тестовый метод делает в транзакции в конце, все вставки / удаления / обновления будут отменены, поэтому мы не оставляем мусор позади.

Пункт 2: нам нужно аннотировать наш тест соответствующей аннотацией RunWith, указывающей, что мы хотим, чтобы механизм Junit / Arquillian был включен.

Пункт 3: мы вводим менеджер сущностей, как мы делали бы в обычном EJB / ресурсе. Имя менеджера постоянства должно совпадать с именем, определенным в test-persistence.xml, так что будьте внимательны.

Пункт 4: аннотация @Before указывает, что метод init () будет запускаться перед каждым тестом. Это отличное место для инициализации любых данных и подготовки среды нашего тестового домена.

Пункт 5: Как вы можете видеть в методе init (), мы сохраняем сущность User, аналогично тому, что мы сделали бы в нашем продукте / реальном коде!

Пункт 6: Фактический метод тестирования, который мы пытаемся запросить для объекта, сохранился позже.

в заключение

Тот факт, что мы уже настроили и подготовили структуру и конфигурацию нашего проекта для использования Arquillian, на самом деле является самой важной вещью. Когда у вас есть готовые базовые блоки, вам нужно написать больше тестов и поэкспериментировать с вашим кодом. Щелкните правой кнопкой мыши на тесте, и, как вы можете видеть, у нас есть зеленый свет успеха, четкий проход. Удачного тестирования!

• Вы можете найти полный код этого поста под тегом post6 в моем репозитории bitbucket.