2011-09-27 2 views
1

Мне удалось получить альтернативные дескрипторы для работы с моими модульными тестами, запущенными на OpenEJB, используя заглушки для зависимых компонентов EJB, когда каждый тест выполняется самостоятельно. Но как только я представляю тестовый пакет, кажется, что дескриптор развертывания взят из первого теста, добавленного в пакет.Альтернативные дескрипторы OpenEJB не работают при использовании набора тестов jUnit

Некоторые коды, чтобы объяснить это лучше. Фасоль испытуемым являются чем-то вроде

@Stateless 
@Local(A.class) 
public class ABean implements A { 
    // Bean implementation, no dependencies 
} 


@Stateless 
@Local(B.class) 
public class BBean implements B { 

    @EJB 
    A aBean; // Dependency to ABean 

    // Rest of the implementation 
} 

И TestCase для B (TestCase для A аналогично, за исключением того, что не установлено свойство для использования альтернативного дескриптора)

public class BBeanTest { 
    private B bean; 

    @Before 
    public void bootContainer() throws Exception { 
     Properties props = new Properties(); 
     props.put(Context.INITIAL_CONTEXT_FACTORY, 
       "org.apache.openejb.client.LocalInitialContextFactory"); 
     props.put("openejb.altdd.prefix", "test"); // Use stubs 

     System.out.println("boot B: " + props); 

     context = new InitialContext(props); 
     bean = (B) context.lookup("BBeanLocal"); 
    } 
} 

И, как это все работает просто отлично, когда выполняется в одиночку. Альтернативный дескриптор вводит реализацию заглушки интерфейса A.

При использовании следующего набора тестов все начинает разваливаться.

@RunWith(Suite.class) 
@Suite.SuiteClasses({ 
    ABeanTest.class, 
    BBeanTest.class 
}) 
public class MySuite { 
     // Empty on purpose, annotations do the trick 
} 

При запуске этого пакета альтернативный дескриптор для тестирования B не используется. Несмотря на то, что вывод, показывающий, что, по крайней мере свойство установлено перед каждым испытанием

boot A: {java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory} 
boot A: {java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory} 
boot A: {java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory} 
boot B: {java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory, openejb.altdd.prefix=test} 
boot B: {java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory, openejb.altdd.prefix=test} 

Если я изменить порядок загрузки тестов в ванной, то есть добавить BBeanTest.class перед тем ABeanTest.class, он будет использовать альтернативный дескриптор , Поскольку ABean не имеет зависимостей, в этом случае это будет работать нормально, но, вероятно, вызывает проблемы с большими настройками с несколькими альтернативными дескрипторами.

Любые указатели?

Заранее спасибо.

EDIT Основываясь на выходе журнала, контейнер фактически загружается только один раз для первого теста, так как он принимает ок. 2,5 секунды для выполнения, в то время как остальные занимают около 0,001 секунды.

EDIT2 OpenEJB версия Apache OpenEJB 3.1.4 сборки: 20101112-03: 32

+0

мне удалось сделать то, что мне нужно с помощью batchtest задачи JUnit ANT. Хорошо работает в случаях, когда «люкс» можно отличить по имени пакета.Ему все равно нужно знать, можно ли использовать jUnit TestSuite с OpenEJB, чтобы при необходимости создать более сложный пакет. – kaskelotti

ответ

1

Основываясь на выходе журнала, контейнер фактически загружен только один раз для первого теста, как это происходит ок. 2,5 секунды для выполнения, в то время как остальные занимают около 0,001 секунды.

Как вы правильно заметили, инициализация происходит только один раз.


@RunWith(Suite.class) 
@Suite.SuiteClasses({ 
    ABeanTest.class, 
    BBeanTest.class 
}) 

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

В вашем случае, поскольку вам нужны разные настройки для двух тестовых классов, я думаю, что сброс экземпляра контейнера в ABeanTest @AfterClass и использование нового в BBeanTest должно сделать это.

This blog post показывает, как

+0

Спасибо @stratwine. Сообщение в блоге, которое вы связали, четко объясняет, как закрыть контейнер между тестами. Просто вызвать Context # close() недостаточно. Также необходимо передать свойство «openejb.embedded.initialcontext.close» со значением «destroy» в InitialContext после его создания. – kaskelotti

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