Каков «правильный» способ написания теста JUnit для EJB? - PullRequest
2 голосов
/ 27 февраля 2012

Я использую IBM RAD 7 (также известный как Eclipse 3.4) и WebSphere 7.

У меня есть проект EJB, который содержит @Stateless EntityService и @Stateless EntityDAO и т. Д.

У меня есть веб-проект, который содержит спокойный веб-сервис JAX-RS, который ищет EntityService с этим URL-адресом JNDI:

ejblocal:entityEAR/entityEJB.jar/EntityService@com.test.EntityServiceLocal

Это все прекрасно работает.

У меня вопрос: каков был бы «правильный» способ написания JUnit тестов для проверки классов EntityService и EntityDAO?

Поскольку система должна работать на сервере WebLogic, я подумал, что я запустил бы приложение, а затем запустил тест JUnit, который проверяет тот же JNDI, который использует веб-служба, но я получаю ошибка:

Naming Manager ... getURLContext cannot find the factory for this scheme: ejbLocal

Любые предложения полезны, как мне подойти к написанию тестов JUnit?

Ответы [ 3 ]

2 голосов
/ 27 февраля 2012

Если вы пишете модульные тесты, то они не должны зависеть от контейнера (потому что они выполняются только в JVM), поэтому вы не можете выполнять в них поиск JNDI. Для тестирования ваших EJB-компонентов и DAO с помощью JUnit может быть очень полезна Mocking Framework (например, EasyMock).

Но если вы заинтересованы в тестировании связи между вашим EJB-компонентом и вашими REST-сервисами, тогда вам нужны интеграционные тесты, и я сомневаюсь, что JUnit может вам здесь помочь. Selenium - это популярный инструмент для интеграционных тестов, и для выполнения тестов вам необходим полнофункциональный контейнер и среда.

1 голос
/ 29 февраля 2012

В общем, JUnit предназначен для написания модульных тестов.В рамках модульного теста вы проверяете работу одного компонента с единственной ответственностью (по крайней мере, он должен нести одну ответственность:)) - все зависимости каким-то образом проверяются (easymock, mockito и т. Д.).Внедрение зависимостей, используемое в EJB, упрощает этот процесс - вы можете создать экземпляр bean-компонента в своем модульном тесте setUp(), используя оператор new (вам не нужен контейнер), а затем внедрить ложные зависимости (так же, как контейнер вводит реальные зависимости).Это подход, который я использую.Другая вещь - это интеграционные тесты, которые проверяют весь сценарий - начиная от вызова веб-службы (или другого метода удаленного фасада) через логику компонентов до запросов к БД.Однако в этом случае вы не проверяете компоненты, стоящие после веб-сервиса / фасада.Просто вывод веб-сервиса для конкретного ввода.

Хороший подход - сначала написать тест (с ошибкой в ​​начале), а затем написать реализацию, чтобы удовлетворить его.Для модульных тестов (один компонент, тесты не запускаются внутри контейнера) я бы порекомендовал JUnit и EasyMock / Mockito.Для интеграционных тестов вы можете использовать Selenium или JUnit + OpenEJB как форму простого контейнера для тестов (особенно если у вас есть удаленный фасад в форме компонента EJB).Кроме того, используя такие инструменты, как SoapUI, вы можете создавать целые сценарии тестирования для своего веб-сервиса - публиковать некоторые данные, получать их, изменять, помещать, продолжать получать, удалять и т. Д.

0 голосов
/ 25 июня 2012

В конце дня я реализовал удаленный интерфейс @Remote для классов Service, которые я хотел протестировать, и выполнил удаленный JNDI-поиск для компонента службы.

как написать тест JUnit, который может видеть мой EJB-сервис?

...