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

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

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

Можно ли автоматически создавать фиктивные классы (ничего не делая или генерируя исключения UnsupportedOperationException) для интеграционных тестов компонентов EJB/CDI? Что-то типа:

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();
    }
}

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


junit cdi jboss-arquillian ejb shrinkwrap
person piotrek    schedule 30.01.2015    source источник
comment
если ваш тест не использует зависимость, зачем вы ее упаковываете?   -  person John Ament    schedule 31.01.2015
comment
Потому что в противном случае контейнер CDI (Weld, поскольку я использую встроенный контейнер Glassfish) будет жаловаться на неудовлетворенные зависимости.   -  person piotrek    schedule 31.01.2015

Ответы (2)


arrow_upward
1
arrow_downward

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

person win_wave    schedule 01.02.2015

arrow_upward
0
arrow_downward

Я использую удаленный вызов EJB для тестирования интеграции вместо Arquillian. хотя мы должны создавать интерфейсы для каждого bean-компонента, нам не нужно создавать альтернативный пакет приложений для интеграционного тестирования, и это обеспечивает более высокую производительность в моем случае. но, конечно, это не работает для бинов CDI. Я разместил запись в блоге о своем случае.

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