Интеграционные тесты EJB со многими зависимостями в Arquillian

У меня часто EJB в зависимости от нескольких (например, 5-10) других EJB/CDI-компонентов, и многие методы используют только их подмножество. Тестирование интеграции (мы используем Arquillian со встроенным контейнером Glassfish 4.0), это больно, потому что я все еще должен предоставлять зависимости для всего графа классов. Я добавляю классы один за другим в архив ShrinkWrap, потому что добавление целых пакетов создало еще больше зависимостей, и я не хочу добавлять все классы, потому что это значительно увеличивает время, необходимое для завершения одного теста. Я также не хочу, чтобы все классы добавлялись для каждого теста, особенно те, которые касались файловой системы или выполняли команды оболочки.Интеграционные тесты EJB со многими зависимостями в Arquillian

Если граф зависимостей растет, я создаю фиктивные объекты, просто реализуя интерфейс EJBs, используя методы, которые бросают UnsupportedOperationExceptions, но он становится утомительным, потому что их много, и трудно сохранить изменения имени класса (вы ожидаете, что существует DummyMyService для MyService, но поскольку он был переименован из OldService, вы создадите еще один манекен, потому что вы не нашли DummyOldService).

Можно ли автоматически создавать фиктивные классы (ничего не делать или бросать UnsupportedOperationExceptions) для интеграционных тестов EJBs/CDI Beans? Что-то вроде:

ShrinkWrap.create(JavaArchive.class, "test.jar") 
    .addClass(MyTestedService.class) 
    .addClass(ImportantDependency.class) 
    .addClass(Dummy.createDummy(DependencyNeededForSomeMethods.class));

для класса, как этот, когда я только хочу, чтобы проверить метод doImportantThings:

@Stateless 
public class MyTestedService { 

    @Inject 
    private ImportantDependency importantDependency; 

    @Inject 
    private DependencyNeededForSomeMethods dependencyNeededForSomeMethods; 

    public void doImportantThings(){ 
     .... 
     importantDependency.doIt(); 
     .... 
    } 

    public void doSomethingElse(){ 
     .... 
     dependencyNeededForSomeMethods.doRarelyNeededThings(); 
     .... 
     importantDependency.doAnotherThing(); 
    } 
}

Или, может быть, есть другой способ борьбы с ним (для рефакторинга классов под исключением контрольная работа)?

источник

2015-01-30 piotrek

Если ваш тест не использует зависимость, зачем вы его упаковываете? –

Потому что в противном случае контейнер CDI (Weld, так как я использую встроенный контейнер Glassfish) будет жаловаться на неудовлетворенные зависимости. – piotrek

Думаю, это не обеспечивает такую функцию. Скорее всего, это признак плохого дизайна. Вы должны изменить структуру пакета. А затем создайте обертки только с нужными пакетами.

источник

2015-02-01 15:29:09

Я использую удаленный вызов EJB для тестирования интеграции вместо Arquillian. хотя нам нужно создавать интерфейсы для каждого компонента, нам не нужно создавать альтернативный пакет приложений для тестирования интеграции, и это дает более высокую производительность для моего случая. но, конечно, это не работает для CDI beans. I posted a blog entry about my case.

источник

2015-02-24 07:12:27

Создание интерфейсов - это то, чего я действительно хочу избежать - это была основная причина этого вопроса - мне пришлось добавлять интерфейсы для создания заглушек. – piotrek

Интеграционные тесты EJB со многими зависимостями в Arquillian

ответ

Смежные вопросы