MQTT is a widely used protocol 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. Also, 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.
One of the most common examples of MQTT usage is in home automation. A mobile phone is a client 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 an MQTT message from the client, it will handle its task correctly by for example 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 MQTT is becoming a very important protocol in the IoT landscape which makes it very important to test this thoroughly.
MQTT in a nutshell
MQTT is a protocol 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’ve also warned him to drive safely. To do 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 how fast the car is moving, including the application. This would be MQTT in a nutshell.
If you want to look at some more in-depth knowledge about MQTT, a good starting point would be the documentation of MQTT: https://mqtt.org.
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.
To start we will need to download Docker and pull the image. This can be done by using the Docker client or simply from command line. If you use command line you can execute the following Docker command: docker pull eclipse-mosquitto
Once this is done, you will 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:
listener 1883
allow_anonymous true
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:
Click to enlarge
More configurations can be set in the mosquitto.conf file, as it can be completely tailored to your own needs. But for the purpose of this demo, the above lines suffice.
Now, we still need to start the containers by ourselves. But we want to automate this, we want to create a test container library, which handles this for us. The strategy we will be using, is to launch a container for each test so that we start with a new broker for each test. We can use the snippet in C# below to achieve this:
click to enlarge
We start by building our 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 will make it easier to test applications using MQTT. Not only are the test 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.
Een full-stack QA engineer, het zoveelste buzzword in IT en familie van de “full stack developer”, betekent niet meer of minder dan DE TESTER DIE ALLES KAN. 💪🏻 Van manueel testen tot het opzetten van een custom built framework of het scripten van performance testen of … Samengevat, een alleskunner pur sang.
6 Reasons why a VCS (Version Control System) as a part of SCM (Software Configuration Management) is undeniably one of the most important architectural tools for any development team (including QA engineers).
Hoe kan je snelheid verhogen in je SDLC (Software Development Life Cycle) zonder in te boeten aan kwaliteit? Testautomatisatie kan hiervoor een oplossing zijn, tenminste als het op een correcte manier wordt toegepast.
Software testspecialist Brightest opent een kantoor in Gent. Na Antwerpen en Genk is dit het derde regionale kantoor voor Brightest. Doel is om op een jaar tijd 20 nieuwe medewerkers aan te trekken en de positie in Oost- en West-Vlaanderen te verstevigen.
Katalon Studio Enterprise, KSE, is an automation tool developed by Katalon Inc. This article will mainly be focused on Web Automation. It will briefly handle the pros and cons of using Katalon in a web environment. Although, the tool also offers options to automate Mobile, API’s and Desktop applications.
1 jaar Brightest Oost, 1 jaar vol eerste keren, 1 jaar mogen samenwerken met gedreven en getalenteerde mensen, een jaar waarvan we hopen dat er nog vele volgen!
