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 it will switch 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.
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.
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:
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.
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 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.
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. It is also easier to maintain as these tests can be developed during the development cycle which 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.
COTS and SaaS products are ready-to-use software systems. Firstly, we take a closer look at the differences between COTS and SaaS systems. After that, we talk about how to successfully implement them within your organization. This will help your organization make informed software purchasing decisions for years to come.
Now in a global market with growing E-commerce importance, these black Fridays are a challenge. More shoppers are leaving their cars in the garage and buy online. So the question for companies is whether their website or application is up for the job, how to prevent it from slowing down or even crashing.
A Gartner survey found that there will be an increase in IT spendings in 2023, despite of the recession. As IT budgets are being allocated as we speak, you may be interested on how implementing a shift-left testing approach. It can help you tackle the recession and hopefully make your company recession proof.
Everyone knows GitHub as a platform for storing Git repositories and collaborating with other developers. But besides storing repositories, GitHub also offers features like Issues, Project boards, Wiki’s and GitHub Actions. In this article we focus on Reusable Workflows and Composite Actions.
If I were to ask you this question in person today, what would your answer be? Clearly, there is some doubt about what exactly is meant by software quality. We have created a simple flowchart to help you visualize software quality and to determine whether you’re on the good side of the software quality matrix.