Question

我正在编写一个使用一些客户端逻辑和一些服务器端逻辑的测试。在客户端，我对一些Web服务进行REST调用，该服务操作数据并将其存储在JMS队列中。我稍后进行JMS调用以查看写入JMS主题的内容，并得到一些令人惊讶的结果。

以下是定义此问题的测试代码的有趣部分：

@Test
@OperateOnDeployment("my-deployable")
public void testMessageInTopic() throws Exception {
    // make a rest call with the minimal request
    makeRequest(getMyXmlAsString());

    // compare the message with the one sent to the topic
    connection = factory.createConnection();
    final Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
    final MessageConsumer consumer = session.createConsumer(topic);
    connection.start();

    System.out.println("### listening for a response");
    final TextMessage receivedMessage = (TextMessage) consumer.receive();
    final String expectedString = "sampleFromTest"

    final String receivedText = receivedMessage.getText();
    System.out.println("### got this message " + receivedText);
    assertEquals("the message in the received topic is the same", expectedString, receivedText);
    System.out.println("#### the message was as expected");
}

makeRequest（final String data）方法执行以下操作：

public makeRequest(final String data) {
    final String url = getAppEndpoint("http://localhost:8080/doit");
    final ClientRequest req= new ClientRequest(url);
    req.header(HttpHeaderNames.CONTENT_TYPE, MediaType.TEXT_PLAIN);
    req.body(MediaType.TEXT_PLAIN, data);
    response = req.post(MyResponse.class);
}

观察日志时，以下是我按顺序收到的消息：

09:38:59,448 INFO  [stdout] (pool-2-thread-1) ### got this message sampleFromTest
09:38:59,448 INFO  [stdout] (pool-2-thread-1) #### the message was as expected
09:38:59,488 INFO  [stdout] (pool-2-thread-2) ### listening for a response

很明显，嵌入式测试和客户端测试相结合并不好用，因为线程化成了一个问题。我可以通过在我的@Before测试方法中进行其余调用，或者通过注入Web服务并以编程方式使用请求进行调用来绕过这个问题。但是，由于我的兴趣在于测试完整的集成路径，因此混合客户端和服务器请求似乎是一个好主意。那么我的问题是，是否可以运行我们发出客户端请求并解析容器收到的数据的场景？

Answer 1

原来我得到了这个差异，因为我在没有添加显式等待的情况下调用了jms的receive（）方法。因此，上述输出是正确的：

09:38:59,448 INFO  [stdout] (pool-2-thread-1) ### got this message sampleFromTest
09:38:59,448 INFO  [stdout] (pool-2-thread-1) #### the message was as expected
09:38:59,488 INFO  [stdout] (pool-2-thread-2) ### listening for a response

为了解决我的问题，我做了类似的事情，在执行更多代码之前添加显式的同步等待：

final TextMessage message = (TextMessage) consumer.receive(15000);

这样，在写完一条消息后，我等待最多15秒，然后再回落。虽然我永远无法证明

### listening for a response

之前从未发生过

09:38:59,448

在最初的问题中，应用这种方法确实解决了这个问题。

Arquillain中的多个主题

1 个答案: