Что такое «правильный» способ написать тест JUnit против EJB?

Question

Я использую IBM RAD 7 (ака Eclipse 3.4) и WebSphere 7.

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

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

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 тестов?

Answer 1

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

Подробнее здесь:

how to write a JUnit test that can see my EJB service?

Answer 2

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

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

Answer 3

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

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