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.
It may be hard to believe, but there are still people who are sceptical about investment in learning. Let us not treat them as ignorant. Instead, let us bring them into the light and help them to see the value that continued learning can bring to themselves and their organisation.
Today’s growing demand to deliver quality software faster requires organizations to search for solutions in Agile, Continuous Integration and DevOps methodologies. Test automation is an essential part of this process, but in a lot of cases testing, manual and automated, often becomes a bottleneck in this process. The reasons can be various, but very often the problem begins with the choice of tooling to support this process. So how can we tackle this? How can we avoid test automation becoming a bottleneck for the organization?
December is voor mij de ‘reset’ knop van het jaar. Alhoewel het nog erg koud is, worden de dagen stilaan weer langer, de oude en zwakke takken worden uit de bomen gewaaid en maken plaats voor nieuwe knoppen.
Op World Quality Day staan we bij Brightest eens extra stil bij dat belangrijke begrip. Kwaliteit kan je in vele vormen vinden: denk maar aan een efficiënte dienstverlening, een topproduct of een performante website. Kwaliteit zit in vele aspecten in het leven. Dat is het mooie eraan. Lees maar even mee.
Since testing is becoming more and more technical, these developer tools are not only interesting for developers, but also for testers. In this post we will be sharing some DevTools features which might benefit you as a tester. In the beginning the DevTools UI might be overwhelming, but if you take your time to get familiar with some of the tabs, you will discover that it will definitely boost your productivity.
Van dale gaat elk jaar op zoek naar het woord van het jaar. Voor ons mag dat gerust “flexibiliteit” zijn. Ook al gaat het niet over een “nieuw” woord, toch omschrijft het 2020 in al zijn facetten. Met dit als inspiratie doopten we onze nieuwe solution “Flex testing”, hier lees je er alles over.