В TDD, почему OpenEJB и почему Arquillian? - PullRequest
7 голосов
/ 09 октября 2011

Я веб-разработчик, закончивший какой-то разработкой Java EE (Richfaces, Seam 2, EJB 3.1, JPA).Для тестирования JPA я использую гиперзвуковой и Mockito.Но мне не хватает более глубоких знаний EJB.

Некоторые могут утверждать, что мы должны использовать OpenEJB и Arquillian, но для чего?Когда мне нужно делать тесты, зависящие от контейнера?Каковы возможные сценарии тестирования, когда мне нужны OpenEJB и Arquillian?

Пожалуйста, просветите меня:)

Ответы [ 2 ]

11 голосов
/ 09 октября 2011

В этом случае есть два аспекта.

  1. Юнит-тесты .Они предназначены для очень быстрого (выполнить весь набор тестов в считанные секунды).Они тестируют очень маленькие куски вашего кода - то есть один метод.Чтобы достичь такого рода детализации, вам нужно смоделировать всю среду, используя, например, Mockito.Вас не интересует:
    • вызов EntityManager и помещение сущностей в базу данных,
    • тестирование транзакций,
    • выполнение асинхронных вызовов,
    • попадание в JMSКонечная точка и т. Д.

Вы издеваетесь над всей этой средой и просто тестируете каждый метод отдельно. Юнит-тесты мелкозернистые и невероятно быстрые.Это потому, что вы можете выполнять их каждый раз, когда вносите важные изменения в код.Если бы они были более сложными и трудоемкими, разработчик не стал бы нажимать кнопку «тестировать» так часто, как следовало бы.

  1. Интеграционные тесты .Это медленнее, так как вы хотите проверить интеграцию между вашими модулями.Вы хотите проверить, правильно ли они «общаются» друг с другом, то есть:
    • - это транзакции, распространяющиеся так, как вы ожидаете,
    • что произойдет, если вы вызовете свой бизнес-метод без транзакциивообще,
    • действительно ли изменения, отправленные вашим клиентом WebServices, действительно влияют на ваш метод конечной точки и добавляет данные в базу данных?
    • что, если моя конечная точка JMS выдаст исключение ApplicationException - будет ли это правильнооткатить все изменения?

Как видите, интеграционные тесты являются грубыми и, как они выполняются в контейнере (или в основном: впроизводственная среда) они намного медленнее.Эти тесты обычно не выполняются разработчиком после каждого изменения кода.

Конечно, вы можете запускать EJB-контейнер во встроенном режиме так же, как вы можете выполнять JPA в Java SE.Дело в том, что искусственная среда предоставляет вам базовые сервисы, но вы закончите настройку и по-прежнему будете иметь меньшую гибкость, чем в реальном контейнере.

Arquillian дает вам возможность создавать производственную средув выбранном контейнере и просто выполните тесты в этой среде (используя источники данных, JMS-адреса и целый ряд других конфигураций, которые вы ожидаете увидеть в производственной среде.)

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

0 голосов
/ 28 ноября 2011

Я посетил Devoxx в этом году и получил шанс ответить на этот вопрос парням из JBOSS.Некоторые из тестовых сценариев (материал, который мне удалось написать):

  • Конфигурация контейнера
  • Интеграция контейнера
  • Границы транзакции
  • Методы обратного вызова объекта
  • Интеграционные тесты
  • Селеновые записи
...