We have taken the decision to use Rabbit MQ as our internal message queue. To understand the way that Rabbit MQ talks with Java applications I decided to create a little Hello World application. Using Rabbit MQ’s Java API guide I created the exploratory test below.
The complete code, in a Maven project, can be found on my github repository here.
The test starts with setting up the connection to the Rabbit MQ broker which is running on localhost. Since the client comes with sensible defaults the connection does not need to be configured with anything but the name, type and durability of the exchange. A queue is then bound to the channel to enable us to send messages.
@Before
public void setUpConnectionAndChannelAndExchange() throws IOException {
ConnectionFactory factory = new ConnectionFactory();
connection = factory.newConnection();
channel = connection.createChannel();
channel.exchangeDeclare(EXCHANGE_NAME, TYPE, DURABLILTY);
queueName = channel.queueDeclare().getQueue();
channel.queueBind(queueName, EXCHANGE_NAME, ROUTING_KEY);
}
The actual test only details the steps needed to verify that the message sent matches the messages received. The implementation will be discussed in each of the supporting methods:
@Test
public void receiveSentMessage() throws InterruptedException, IOException {
givenMessageIsSentTrhoughConfiguredChannel();
whenTheMessageIsRetrivedFromTheChannel();
thenTheReceivedMessageShouldMatchTheSentMessage();
}
To send a message to the MQ we simple publish it to the given exchange using the channel:
private void givenMessageIsSentTrhoughConfiguredChannel() throws IOException {
channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, null, MESSAGE.getBytes());
}
We then pick up the message using a consumer. When implementing this in production code the producer and the consumer should not be running in the same thread since both are blocking. But since we are only testing the availability of the MQ the blocking is actually working or out advantage.
private void whenTheMessageIsRetrivedFromTheChannel() throws IOException, InterruptedException {
QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume(queueName, AUTO_ACK, consumer);
QueueingConsumer.Delivery delivery = consumer.nextDelivery();
message = new String(delivery.getBody());
channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
}
The last step of the test is to assert that we received the same message as we sent:
private void thenTheReceivedMessageShouldMatchTheSentMessage() {
assertEquals(MESSAGE, message);
}
When the test is done we need to close the channel and the connection:
@After
public void closeChannelAndConnection() throws IOException {
channel.close();
connection.close();
}
The benefits of using this approach to understand new technology is that the tests can be put to use to verify the integrity of the libraries and the MQ used when running automated integration tests rather then just writing throw away code.
If you find the structure of the test code different you can find an explanation in this article which discusses the drivers behind the design as well as the given-when-then pattern used in the test method.
We have taken the decision to use Rabbit MQ as our internal message queue. To understand the way that Rabbit MQ talks with Java applications I decided to create a little Hello World application. Using Rabbit MQ's Java API guide I created the exploratory test below.
The complete code, in a Maven project, can be found on my github repository here.
The test starts with setting up the connection to the Rabbit MQ broker which is running on localhost. Since the client comes with sensible defaults the connection does not need to be configured with anything but the name, type and durability of the exchange. A queue is then bound to the channel to enable us to send messages.
[java]
@Before
public void setUpConnectionAndChannelAndExchange() throws IOException {
ConnectionFactory factory = new ConnectionFactory();
connection = factory.newConnection();
channel = connection.createChannel();
channel.exchangeDeclare(EXCHANGE_NAME, TYPE, DURABLILTY);
queueName = channel.queueDeclare().getQueue();
channel.queueBind(queueName, EXCHANGE_NAME, ROUTING_KEY);
}
[/java]
The actual test only details the steps needed to verify that the message sent matches the messages received. The implementation will be discussed in each of the supporting methods:
[java]
@Test
public void receiveSentMessage() throws InterruptedException, IOException {
givenMessageIsSentTrhoughConfiguredChannel();
whenTheMessageIsRetrivedFromTheChannel();
thenTheReceivedMessageShouldMatchTheSentMessage();
}
[/java]
To send a message to the MQ we simple publish it to the given exchange using the channel:
[java]
private void givenMessageIsSentTrhoughConfiguredChannel() throws IOException {
channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, null, MESSAGE.getBytes());
}
[/java]
We then pick up the message using a consumer. When implementing this in production code the producer and the consumer should not be running in the same thread since both are blocking. But since we are only testing the availability of the MQ the blocking is actually working or out advantage.
[java]
private void whenTheMessageIsRetrivedFromTheChannel() throws IOException, InterruptedException {
QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume(queueName, AUTO_ACK, consumer);
QueueingConsumer.Delivery delivery = consumer.nextDelivery();
message = new String(delivery.getBody());
channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
}
[/java]
The last step of the test is to assert that we received the same message as we sent:
[java]
private void thenTheReceivedMessageShouldMatchTheSentMessage() {
assertEquals(MESSAGE, message);
}
[/java]
When the test is done we need to close the channel and the connection:
[java]
@After
public void closeChannelAndConnection() throws IOException {
channel.close();
connection.close();
}
[/java]
The benefits of using this approach to understand new technology is that the tests can be put to use to verify the integrity of the libraries and the MQ used when running automated integration tests rather then just writing throw away code.
If you find the structure of the test code different you can find an explanation in this article which discusses the drivers behind the design as well as the given-when-then pattern used in the test method.
