Как вы проводите модульное тестирование кода Java EE?

Если под модульным тестированием вы имеете в виду ... модульное тестирование (изолированное тестирование модуля), тогда вам на самом деле не нужна какая-либо конкретная структура, поскольку EJB3.0 - это не что иное, как аннотированные POJO и, следовательно, могут быть относительно легко тестируется без специального приспособления.

Теперь, если вы имеете в виду что-то еще - например, Integration Testing или Functional Testing - тогда, да, инструменты могут помочь и упростить вещи (но вам следует действительно начну использовать правильную терминологию :) Предположу, что это то, что вы имеете в виду.

Во-первых, JUnitEE кажется мертвым и устаревшим, и я даже не уверен, что у него есть что-нибудь для EJB3.x. Во-вторых, меня не впечатлила поддержка Java EE 5 в Cactus и необходимость развертывания тестов Cactus болезненна (я думаю, что Cactus был хорош для J2EE 1.4, но теперь немного устарел ). Таким образом, остается Ejb3Unit, который, на мой взгляд, является лучшим вариантом, особенно если вы хотите запустить вне контейнера, т.е. без реального развертывания приложения (намного быстрее).

Если вы хотите запустить тесты в контейнере, вы действительно можете использовать встроенный контейнер, и я сейчас предпочитаю GlassFish v3, даже для Java EE 5 (я могу ошибаться, но я очень разочарован время начала последних выпусков JBoss, поэтому я не уделяю им особого внимания). Образец кода (который вы могли бы используйте из ваших тестов) или Использование плагина maven для встроенной стеклянной рыбы v3 (если вы используете maven ).

Другой вариант - упаковать и развернуть ваше приложение с помощью Cargo, а затем запустить несколько тестов для развернутого приложения (с помощью Selenium или инструмент BDD, например). Это может быть полезно, если вы хотите запускать сквозные тесты с контейнером, который не предоставляет никакого встроенного API.

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

Поскольку вас интересует модульное тестирование, я рекомендую JUnit. Вы можете выполнить модульное тестирование методов в основных классах. Если у вас возникают трудности с написанием модульных тестов с использованием JUnit, то, вероятно, конструкция не является модульной и сильно связана. Сначала сосредоточьтесь на своей основной функциональности и протестируйте ее с помощью JUnit.

Я столкнулся с той же проблемой запуска интеграционных тестов на основе JUnit в контейнере Java EE 6 (если быть точным, Glassfish v3), и после долгого просмотра и поиска я не смог найти решение, которое действительно соответствовало бы моим потребностям. , поэтому я написал свой собственный, теперь опубликованный как jeeunit в Google Code.

Я бы не назвал это тестовой средой, на самом деле это всего лишь горстка классов, обеспечивающих связь между JUnit и Embedded Glassfish.

Общая идея похожа на Cactus, ваши тесты запускаются в контейнере и запускаются сервлетом извне.

jeeunit поддерживает JUnit 4, Glassfish v3, CDI и генерирует стандартные отчеты JUnit в формате XML точно так же, как Ant или Maven Surefire (фактически, я повторно использовал некоторый код из Ant для создания отчетов).

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

http://jglue.org/cdi-unit/

Он подходит для Java SE, а также поддерживает фиктивные области запроса, сеанса и разговора для тестирования веб-приложений.

Он маленький и быстрый, и это здорово, когда у вас много модульных тестов.