MQTT protocols and the Internet of Things

The origin of MQTT

The MQTT protocol is a widely used for machine-2-machine communication. It was created in 1999 by Andy Stanford-Clark and Arlen Nipper for the oil and gas industry. They needed a way to inter-communicate with different systems which could not communicate directly with each other. Back then, digital communication and processing power was not cheap. The solution had to be lightweight with a small code footprint and a minimal network bandwidth. Nowadays we have plenty of power and digital communication is much more reliable than it used to be.

 

Example of MQTT protocol usage

One of the most common examples of MQTT protocol usage is in home automation. The client is a mobile phone, which will send a MQTT message to a broker. Mostly the broker is the heart or brain of the home automation system. Once the broker receives a MQTT message from the client, it will handle its task correctly, for example by switching off a light. If another client wants to know the state of the light, it will send another MQTT message on its turn to ask the state of the broker.

Other than home automation, MQTT is also gaining popularity in the automotive industry. HiveMQ, a popular MQTT broker system, has been collaborating with companies like BMW, Audi, SiriusXM to build connected cars. Traditional HTTP and SMS communication are not suited to build a connected car architecture due to many reasons. In short, the MQTT protocol is becoming very important in the IoT landscape which makes it very important to test this thoroughly.

 

MQTT in a nutshell

The MQTT protocol is based on a publish/subscribe paradigm. An MQTT network consist of clients and a broker. The clients will publish and subscribe to topics and a broker ensures that every message is distributed to the clients that are subscribed to the topics. Let us say you have borrowed your car to a friend, but you also warned him to drive safely. To check this, you have installed an application on your phone which allows you to know how fast he or she is driving. To monitor the actual speed, this application will have to subscribe to the topic ‘Speed’. Every time your car then publishes a message to this topic, all clients subscribed to the topic will receive a message with how fast the car is moving, including the application. This would be MQTT in a nutshell.

 

 

Building integration tests for your MQTT application

There are a couple of ways to test an MQTT application. In the past there were a lot of integrated tests, which used a broker that is public on our network inside a test environment. Although this way of testing has it is benefits, it is not a very agile way to test your MQTT interface during development. For example, if there is a network problem and the broker cannot be reached, this could cause our tests to misbehave. Another problem arises when executing multiple tests at once. Test engineers can interfere with each other by uploading different subscription configurations. To tackle these problems, it is important to keep the following guidelines in mind:

• Tests should be isolated and not depend on external dependencies
• Tests should test only one component/module

To mitigate these problems, we can use docker and test containers.

 

An example

A good tutorial on this by using Java can be found in the documentation of HiveMQ: https://www.hivemq.com/blog/

In this example we use a Mosquitto docker image and a dotnet implementation of a testcontainer library. Both can be found at the following locations:

• https://github.com/HofmeisterAn/dotnet-testcontainers
• https://hub.docker.com/_/eclipse-mosquitto

 

STEP 1

For starters, we need to download Docker and pull the image. Use the Docker client to do this or use command line. If you use command line, you can execute the following Docker command: docker pull eclipse-mosquitto.

 

STEP 2

Once this is done, you need a configuration file.
à Create a folder on your C drive called “mosquitto” and create another folder inside it called “config”.
à Ready? Create a file called “mosquitto.conf” and place the following 2 lines inside:

1. listener 1883
2. allow_anonymous true

 

STEP 3

Following, you can start the container manually by executing the following command:
docker run -it -p 1883:1883 -v C:\mosquitto:/mosquitto/ eclipse-mosquitto
Next the image is launched, and you can see in the Docker UI that the image is running:

 

 

You can set more configurations in the mosquitto.conf file, it can be completely tailored to your own needs. For the purpose of this demo, the above lines suffice.

 

STEP 4

Now, we still need to start the containers ourselves. But we want to automate this. We want to create a test container library, which handles this for us. The strategy we use, is to launch a container for each test. So, we start with a new broker for each test. We can use the snippet in C# below to achieve this:

 

 

For starters, we build a container with the Mosquitto image and bind our ports. Then, we mount our Mosquitto directory to our container so that the configuration is set. Once the container is built, we can start it and perform our MQTT tests. By executing the tests using this fixture, we can run multiple tests the same time. The only downside is that we need to specify a port per test.

 

 

 

Conclusion

Using Docker makes it easier to test applications using MQTT. Not only are the tests completely independent of external dependencies, which should not be in scope for integration tests. It also makes the setup easy and fast. Furthermore, you can run multiple tests in parallel, which cannot be done when you test using the actual MQTT broker. Where multiple tests can interfere each other. Additionally, it is easier to maintain as these tests can be developed during the development cycle. Wich results in a faster release and better quality of the software product.

However, bear in mind that these tests are not a complete replacement for E2E tests. But they are a must-have in a good QA process and are complemented by E2E testing.