Как вы тестируете код Java EE?
Не делайте этого.
Если вы абсолютно уверены, что хотите получать веб-контент из среды SQL, то насколько я знаю две возможности:
- Write пользовательский MySQL UDF в C (как упоминалось в bobince). Потенциально потенциально может быть огромная работа, в зависимости от вашего опыта работы на C, насколько вы хотите безопасности, насколько вы хотите, чтобы UDF был следующим: например. Просто GET-запросы? Как насчет POST? ГЛАВА? и т. д.
- Используйте другую базу данных, которая может сделать это. Если вы довольны SQL, возможно, вы можете сделать это с помощью PostgreSQL и одного из оснащенных языков, таких как Python или PHP.
Если вы не слишком суетились о том, чтобы придерживаться SQL, вы можете использовать что-то вроде eXist . Вы можете сделать это довольно легко с помощью XQuery и могли бы легко изменить результаты в соответствии с вашей схемой (а не просто вставлять их в поле blob) или сохранить страницу «как есть» в качестве документа xhtml в БД.
Затем вы можете быстро запускать запросы во всех документах, например, получить все ссылки или цитаты или что-то еще. Вы даже можете применить XSL к такому результату с очень небольшой дополнительной работой. Отлично, если вы сохраняете страницы для справки и хотите приспособить результаты к личным «интранет-стильным» приложениям.
Также, поскольку eXist ориентирован на документ, у него есть много отличных методов для нечеткого текста поиск в поисковых системах, поиск по слову и большой текстовый индекс (намного лучше, чем MySQL). Идеально, если вы после выполнения некоторого интеллектуального анализа данных на контенте, например: найдите мне все документы, где слово типа « burger » в 50 словах «hotdog», где слово не находится в Список UL. Попробуйте сделать , что является родным в MySQL!
Как в сторону, так и без злого умысла; Я часто задаюсь вопросом, почему eXist пересматривается, когда люди строят CMS. Его база данных, которая может хранить содержимое в своем собственном формате (XML или его подмножество (x) HTML), запросит его с легкостью в своем родном формате и может перевести его из его собственного формата с мощным языком шаблонов, который выглядит и действует как его собственный формат . Иногда SQL просто неправильно для работы!
Извините. Не значит, что вафли! : - $
3 ответа
Если под Unit Testing вы имеете в виду. ...тестирование модулей (тестирование модуля по отдельности), то на самом деле вам не нужен какой-либо конкретный каркас, так как EJB3.0 - это не более чем аннотированные POJO, и, таким образом, вы можете сравнительно легко протестировать его без специального приспособления.
Теперь, если Вы имеете в виду что-то другое - например, Интеграционное тестирование или Функциональное тестирование - то, да , инструменты могут помочь и упростить вещи (но Вы действительно должны начать использовать правильную терминологию :) Я полагаю, что это то, что Вы имеете в виду.
Во-первых, JUnitEE кажется мертвым и устаревшим, и я даже не уверен, что в нем есть что-нибудь для EJB3.x. Во-вторых, я не впечатлен поддержкой Java EE 5 из Cactus и необходимость развертывания тестов Cactus болезненна (я думаю, что Cactus был хорош для J2EE 1.4, но сейчас немного устарел). Поэтому мы остаёмся с Ejb3Unit, который, на мой взгляд, является лучшим вариантом, особенно если вы хотите запустить из контейнера тестов, т.е. без реального развертывания приложения (намного быстрее).
Если вы хотите запустить в тесте container, то вы действительно можете использовать встроенный контейнер, и в настоящее время я предпочитаю GlassFish v3, даже для Java EE 5 (возможно, я ошибаюсь, но я очень разочарован временем начала работы последних релизов JBoss, так что это не привлечет много моего внимания). Смотрите пост GlassFish Embedded Reloaded, сервер приложений в вашем кармане для получения примерного кода (который вы можете использовать в своих тестах) или Использование плагина maven для v3 embedded glassfish (если вы используете 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 и генерирует стандартные XML отчеты JUnit так же, как Ant или Maven Surefire (фактически, я повторно использовал некоторый код из Ant для генерации отчетов).