发送 JMS 消息的单元测试代码

发布于 2024-07-09 03:11:00 字数 202 浏览 3 评论 0原文

我有一个类,在完成一些操作后,会发送一条 JMS 消息。 我想对“东西”进行单元测试,但不一定是消息的发送。

当我运行测试时,“东西”呈绿色条,但在发送消息时失败(应该是,应用程序服务器未运行)。 做到这一点的最佳方法是什么,是模拟消息队列,如果是的话,是如何完成的。

我正在使用 Spring,并注入“jmsTemplate”和“queue”。

I have a class that after it does some stuff, sends a JMS message.
I'd like to unit test the "stuff", but not necessarily the sending of the message.

When I run my test, the "stuff" green bars, but then fails when sending the message (it should, the app server is not running).
What is the best way to do this, is it to mock the message queue, if so, how is that done.

I am using Spring, and "jmsTemplate" is injected, along with "queue".

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

梦魇绽荼蘼 2024-07-16 03:11:00

我使用的最简单的答案是取消消息发送功能。 例如,如果您有这样的:

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

如果被删除或模糊的代码量很大,我不会使用匿名内部类,而只是使用“普通”内部类。

The simplest answer I would use is to stub out the message sending functionality. For example, if you have this:

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

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

Then I would write a test that obscures the sendMessage behavior. For example:

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

If the amount of code that is stubbed out or obscured is substantial, I would not use an anonymous inner class but just a "normal" inner class.

抹茶夏天i‖ 2024-07-16 03:11:00

您可以注入一个模拟的 jmsTemplate。

假设使用 easymock,类似

JmsTemplate mockTemplate = createMock(JmsTemplate.class)

That 的东西就可以解决问题。

You can inject a mocked jmsTemplate.

Assuming easymock, something like

JmsTemplate mockTemplate = createMock(JmsTemplate.class)

That would do the trick.

若言繁花未落 2024-07-16 03:11:00

关于如何在更大的应用程序中组织所有这些测试存根/模拟...

我们构建和维护一个更大的企业应用程序,它是使用 Spring 配置的。 真正的应用程序作为 EAR 在 JBoss 应用程序服务器上运行。 我们使用 beanRefFactory.xml 定义 Spring 上下文

<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 的数据源) )。

Regarding how to organise all those test stubbing / mocks in a larger application...

We build and maintain a larger Enterprise App, which is configured with Spring. The real App runs as EAR on a JBoss Appserver. We defined our Spring context(s) with a 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>

For running the unit tests, we just use a different beanRefFactory.xml, which exchanges the BasicServices to use a test version. Within that test version, we can define beans with the same names as in the production version, but with a mock/stub or whatever implementation (e.g. database uses a local Apache DPCP pooled datasource, while the production version uses the data source from the Appserver).

故事↓在人 2024-07-16 03:11:00

另一个选择是 MockRunner,它为 JDBC、JMS、JSP、JCA 和 EJB 提供模拟环境。 这允许您像在“真实”情况下一样定义队列/主题并简单地发送消息。

Another option is MockRunner which provides mock environments for JDBC, JMS, JSP, JCA and EJB. This allows you to define the queues/topics just like you would in the "real" case and simply send the message.

指尖上的星空 2024-07-16 03:11:00

这是使用 jMock 单元测试的完美候选者,因为您的服务器未运行,但您将使用 jMock 来模拟与服务器的交互。

This is the perfect candidate to use jMock unit testing since your server is not running but you would use jMock to simulate interaction with the server.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文