Код модульного тестирования, отправляющий сообщения JMS

Question

У меня есть класс, который после того, как он что-то делает, отправляет сообщение JMS. Я хотел бы протестировать «материал», но не обязательно отправку сообщения.

Когда я запускаю свой тест, «наполняются» зелеными полосами, но затем не работают при отправке сообщения (должно быть, сервер приложений не работает). Каков наилучший способ сделать это - это смоделировать очередь сообщений, если это так, как это сделать.

Я использую Spring, и вставляется «jmsTemplate» вместе с «queue».

Answer 1

Самый простой ответ, который я бы использовал, - отключить функцию отправки сообщений. Например, если у вас есть это:

public class SomeClass {
    public void doit() {
        //do some stuff
        sendMessage( /*some parameters*/);
    }

    public void sendMessage( /*some parameters*/ ) { 
        //jms stuff
    }
}

Тогда я бы написал тест, который затемняет поведение sendMessage. Например:

@Test
public void testRealWorkWithoutSendingMessage() {
    SomeClass thing = new SomeClass() {
        @Override
        public void sendMessage( /*some parameters*/ ) { /*do nothing*/ }
    }

    thing.doit();
    assertThat( "Good stuff happened", x, is( y ) );
}

Если объем кода, который заглушается или скрывается, значителен, я бы не использовал анонимный внутренний класс, а просто "нормальный" внутренний класс.

Answer 2

Вы можете добавить поддельный jmsTemplate.

Предполагается, что easymock, что-то вроде

JmsTemplate mockTemplate = createMock(JmsTemplate.class)

Это бы сработало.

Answer 3

Это идеальный кандидат для использования модульного тестирования jMock, так как ваш сервер не работает, но вы должны использовать jMock для имитации взаимодействия с сервером.

Answer 4

Относительно того, как организовать все эти тестовые заглушки / макеты в более крупном приложении ...

Мы создаем и поддерживаем крупное корпоративное приложение, которое настроено на использование Spring. Настоящее приложение работает как EAR на сервере приложений JBoss. Мы определили наш контекст Spring с помощью beanRefFactory.xml

<bean id="TheMegaContext"
          class="org.springframework.context.support.ClassPathXmlApplicationContext">
    <constructor-arg>
        <list>
            <value>BasicServices.xml</value>
            <value>DataAccessBeans.xml</value>
            <value>LoginBeans.xml</value>
            <value>BussinessServices.xml</value>
            ....
        </list>
    </constructor-arg>
</bean>

Для запуска модульных тестов мы просто используем другой файл beanRefFactory.xml, который обменивает BasicServices для использования тестовой версии. В этой тестовой версии мы можем определять bean-компоненты с теми же именами, что и в рабочей версии, но с макетом / заглушкой или любой другой реализацией (например, база данных использует локальный источник данных Apache DPCP, а в рабочей версии используется источник данных из Appserver ).

Answer 5

Другим вариантом является MockRunner , который предоставляет фиктивные среды для JDBC, JMS, JSP, JCA и EJB. Это позволяет вам определять очереди / темы так же, как в «реальном» случае, и просто отправлять сообщение.