Зачем тестировать ejb3 во встроенном контейнере? - PullRequest
Новая
       8

Зачем тестировать ejb3 во встроенном контейнере?

1 голос
/ 01 ноября 2010

Это может быть глупый вопрос, поскольку почти все предпочитают использовать встроенный контейнер для тестирования EJB, но я должен уточнить это из-за недостатка опыта.Кроме того, некоторые утверждают, что встроенные контейнеры не воспроизводят реальной ситуации развертывания на реальном сервере приложений.Итак, при тестировании ejb3, почему указывается использовать встроенные контейнеры вместо автономного контейнера?Заранее спасибо.

Ответы [ 3 ]

2 голосов
/ 01 ноября 2010

Время.

Тестирование EJB на полнофункциональных серверах приложений обычно занимает много времени из-за приложения.Сервер должен «раскручиваться» всякий раз, когда вносятся изменения, поэтому тратится много времени.Поэтому встроенные контейнеры, такие как OpenEJB , могут сэкономить вам много времени.Встраиваемый Glassfish также является опцией в наши дни, хотя я лично не пробовал его.

1 голос
/ 02 ноября 2010

Вот наиболее важные аргументы, которые я нашел. Пожалуйста, прокомментируйте это или добавьте свои собственные соображения о тестировании с встраиваемыми контейнерами против реального контейнера сервера приложений . Спасибо.

  1. использование встроенного метода тестирования контейнера обеспечивает гибкость (вам просто нужно добавить новые библиотеки в путь к классам). насколько я понимаю, если мы хотим иметь возможность доставить проект тестирования для нескольких серверов приложений, мы не должны быть привязаны к контейнеру сервера приложений при реализации тестов. некоторые серверы приложений могут использовать определенные аннотации или дескрипторы развертывания, если они используются, то вы привязаны к серверу приложений
  2. встроенные контейнеры легче, что означает сокращение времени на проведение тестов. Реальный appserver испытывает трудности с автоматическим запуском и остановкой или может зависнуть. поэтому создание полностью автоматизированного процесса тестирования с использованием реального сервера приложений может оказаться слишком сложным ...
  3. другая проблема - это природа большинства приложений Java EE без сохранения состояния. после вызова метода границы транзакции (например, сессионный компонент без сохранения состояния) все JPA-объекты становятся отсоединенными. клиент теряет свое состояние. это вынуждает вас переносить весь контекст между клиентом и сервером - большая нагрузка, каждое изменение состояния клиента должно быть объединено с сервером
  4. со встроенным контейнером у вас есть один процесс, который выполняет все (тесты и ejbs), с реальным сервером приложений вы должны координировать 2 процесса (AppServer и Tests)
  5. для полного тестирования, конечно, вам также нужны тесты на реальном сервере приложений. на разных серверах могут быть свои особенности, например загрузка классов и т. д. встроенные контейнеры, тем не менее, помогают тестировать логику (тестирование модулей и интеграцию модулей), поэтому для ежедневного автоматического тестирования этого может быть достаточно и просто.
0 голосов
/ 10 ноября 2010

Встроенный контейнер выполняется намного быстрее (запуск / остановка), чем полный контейнер -> это наверняка повлияет на разработчика.Настройку / настройку проще автоматизировать, особенно при непрерывной интеграции.С другой стороны, поскольку некоторые встроенные функции отключены во встроенном контейнере, вы не можете все протестировать.

Возможно, вы захотите изучить http://www.jboss.org/arquillian, чтобы иметь оба варианта.С сайта:

Arquillian позволяет тестировать бизнес-логику в удаленном или встроенном контейнере.Кроме того, он может развернуть архив в контейнере, чтобы тест мог взаимодействовать как удаленный клиент.

В конце концов, это зависит от типа EJB, которые вы хотите протестировать.Некоторые сложные сценарии не будут работать во встроенном контейнере без насмешек над некоторыми внешними сервисами.В моих проектах мы тестируем EJBS с помощью созданного нами пользовательского контейнера-макета (сверхбыстрого и простого в использовании) и, если все идет хорошо, мы тестируем на реальных условиях полноценный JBoss, используя API удаленного управления, почти как Arquillian.1011 *

Надеюсь, это поможет.

...