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 term die de laatste tijd nogal snel in de mond wordt genomen is een “Test Automation Framework”, maar wat is het nu eigenlijk een Test Automation Framework? Waarom gebruiken we dit? Wat zijn de voordelen, en zijn er ook nadelen aan verbonden?
Playwright by Microsoft is the newest addition to the Headless Browser Testing frameworks. It is built by the same team which created Puppeteer, the headless browser testing framework for Google Chrome.
Met dank aan onze fantastische #brightcrew mogen we ons sinds maart officieel a Great Place To Work noemen. Oh yes, We’re Certified! En daar zijn we geweldig trots op. #aimhigh
Automation frameworks are gaining popularity as a solution for automating complex applications. One of the main problems using a scripted automation framework is maintenance. The Page Object Model (POM) creates a layer of abstraction between the automated tests and the page under test.
Op 1 april vierden we de tweede verjaardag van Brightest East, in mei is het feest in Brightest West voor hun eerste levensjaar. Tijd voor een interview met de regionale managers Thomas Peeters en Stef Geeurickx van Brightest West en David Vandingenen en Kevin Pieters van Brightest East.
Since mid-January Belgian Friday night equals “masked singer-night”; a tv-show where celebrities are hidden inside beautiful costumes, the audience needs to guess who’s inside and every week one “character” is unmasked. This made me think, what about the character “software tester”? The name implies a clear role, but reality is different. A software tester has many roles hidden under its mask, let us explore!
If we compare the OWASP 2017 top 10 security risks with the one of 2021, we see that broken access control went from the 5th to the 1st place. Surely a good reason to see what broken access control includes and how to prevent access control anomalies.
