MQTT Test Steps

What’s new in version 1.5

  • New Drop MQTT Connection test step
  • Centralized management of connections to MQTT servers which allows to share a connection between test steps of a project
  • The possibility to connect to a MQTT server  with switched off “Clean Session” mode
  • The possibility to specify a Will Message for a connection to a MQTT server
  • The possibility to run single Publish or Receive test steps from a test step editor
  • Get Data context menu which helps to include Property Expansion expression into test step fields
  • Some bug fixes

MQTT Test Steps

MQTT (MQ Telemetry Transport) is a messaging protocol that uses a publish/subscribe design intended to be lightweight for those situations when network bandwidth may be constrained. It is widely used in emerging technologies for the Internet of Things as it is an ideal Machine-to-Machine (M2M) communication protocol. You can read more about MQTT here.

This plugin allows publish messages to MQTT servers, subscribe and receive messages from them. It adds 3 new test steps:

  1. Publish using MQTT – to publish a message
  2. Receive MQTT message – to subscribe to a topic (or topics) and receive a message
  3. Drop MQTT connection – to terminate connection with MQTT server

To see how your MQTT broker performs under heavy load, you create a load test for it in LoadUI NG. You first create an MQTT test case in SoapUI NG, and then create a load test that simulates this test case with dozens and hundreds of virtual users running on a locally or remote machines. See the LoadUI NG tutorial for more information about creating load tests.

Connections management

Before you start, you should specify the MQTT server (or servers) which you want to use and configure your connection settings. Every MQTT-related test step has the Connection combo-box. You can choose “<New Connection…>” item to create a new connection.



The Create New Connection dialog will appear:



You should specify the following settings for the connection (note that the connection may be used in any test case in the project, so only project level property expansions will work correctly for connection settings):

Name
The unique name to identify a connection within test steps (this name will appear in the Connection combo-box of the test steps later).

Server URI
This is the URI of the MQTT server. URI should contain the protocol being used:
    tcp://  to connect using a plain TCP socket.
    ssl://  to connect using a secure SSL/TLS socket.
URI may also contain a port number. If the port is not specified, it will default to 1883 for tcp://" URIs, and 8883 for ssl:// URIs.
Example of URI:
ssl://localhost:8883

Client ID
The client identifier is used by the server to identify a client. It must be unique across all clients connecting to the same server. This field is optional. If it is left empty, a unique client identifier will be generated for every test case run. You can still fill it with a fixed value if the MQTT server makes some specific handling of the client identifier.

Clean Session
If this checkbox is unchecked, the plugin and MQTT Server will store Session state to enable reliable messaging to continue across a sequence of Network Connections. For example, if this option is unchecked and a connection is lost during test case execution, the Receive test step will still catch QoS 1, QoS 2 (and maybe QoS0 – it depends on the server) messages  if it is able to reconnect. (However, the plugin might establish the connection with set “clean session” mode the first time to ensure that testing always starts with the same initial condition).

Authentication
Check this option if the MQTT server requires authentication.

Login, Password
These fields are required if the MQTT server requires authentication.

Hide
If this checkbox is unchecked, the password value will be visible in the Password text edit box. If you want to keep the password hidden, check this box.

Will Message
If checked, the special message will be published by the MQTT server if the connection is lost unexpectedly. The rest of the dialog fields are related to this message and are disabled if this setting is unchecked.

Topic
The topic of the Will Message. Only clients which are subscribed to this topic will receive the Will message if the connection is terminated unexpectedly.

Message type
Type of the Will Message. The following values are available:

  • JSON
  • XML
  • Text (UTF-16)
  • Text (UTF-8)
  • Content of file
  • Integer
  • Long (8 bytes)
  • Float
  • Double

JSON and XML options send the message as UTF-8 text and display a convenient editor for the message. Note that all of the number types are sent as binary data.

Message
This is the actual payload of the Will Message.

Quality of Service
This is the Quality of Service level to be used when publishing the Will Message.

Retained
If checked, the Will Message will be a retained message

After you close the Create New Connection by clicking Ok, this connection will be assigned to the current test step. To use this connection with another test step,choose it from the Connection combo-box in the test step editor. If you want to browse all connections related to the project or remove some needless connections, open any Publish or Receive test step editor and click on the Configure MQTT Connections of the Project toolbar button:



The Configure Connections to MQTT Servers dialog will appear:



This dialog allows you to manage all connections with MQTT servers used for the current project. 
 

Publish Test Step


This test step publishes a message to a topic on the server. 


Connection
Choose the MQTT server or select <New Connection…> to create a new connection for this test step.

Configure
Click this button if you want to customize the connection selected for this test step. The Configure Connection dialog will appear.

Topic
The topic of the message. Only clients which are subscribed to this topic will receive the message published by this test step.

Message type
Type of  message to publish. The following values are available:

 

  • JSON

  • XML

  • Text (UTF-16)

  • Text (UTF-8)

  • Content of file

  • Integer

  • Long (8 bytes)

  • Float

  • Double

JSON and XML options send the message as UTF-8 text and display a convenient editor for the message you want to publish. Note that all of the number types are sent as binary data.

Message
This is the actual payload of the message you want to publish.

Quality of Service
Choose the Quality of Service you want to use when delivering the message.

Retained
This checkbox lets you decide whether this message should be retained by the server. If you check the box, all new clients will receive the retained message right after they subscribe to the specified topic. If you leave this unchecked, only currently subscribed clients will receive it.

Timeout
The test step will fail if a connection to MQTT server is not established and acknowledgment that published message is received by server within a specified period.

 

Receive Message Test Step

This test step subscribes to specified topics (if subscription was not made before), creates a message queue (if it was not created before), extracts a message with specified topics if it is contained in the queue or waits until it is appears in the queue.

Connection
Choose connection with MQTT server which you want to receive message from or <New Connection…> item to create a new connection for this test step
 
Configure
Press this button if you want to customize the connection selected for this test step. The Configure Connection dialog which is analogous to Create New Connection dialog will appear.

Subscribed topics
Enter a list of topics or topic filters you want this test step to listen for. Only messages with a corresponding topic will be extracted from the queue by this test step. Every item in this list must be on its own line. Although multi-line topic names are supported by the MQTT standard, this test step does not support them. The format of topic filters is described in MQTT standard here.

On unexpected topic
This setting specifies what to do if a message with a topic that does not correspond to Listened topics is next in the queue.

  • Choose Discard to remove all inappropriate messages until appropriate message is met.

  • Choose Ignore to skip all inappropriate messages and, maybe, leave them to future analysis.

  • Choose Fail to mark this test step as failed.

Quality of service
Choose the maximum quality of service at which to subscribe. Messages published at a lower quality of service will be received at the published QoS. Messages published at a higher quality of service will be received using the QoS specified on the subscribe.

Expected message type
This field specifies how to interpret a received message payload. If a message cannot be treated as a specified type, the test step will fail. The following options are available:

  • UTF-8

  • UTF-16

  • Integer number

  • Float number

  • Raw binary data (shown as a hexadecimal digits sequence).

Timeout
The test step will fail if a message isn't received within a specified period.

Received message
The topic and payload of a message which was received as a result of the test step execution.

Drop Connection Test Step

This test step disconnects from the MQTT server which is useful if you are testing scenarios in which dropped connections are a factor.



Connection
Choose the connection with MQTT server which you want to terminate or <New Connection…> item to create a new connection for this test step from the dropdown list.
 
Configure
Press this button if you want to customize the connection selected for this test step. The Configure Connection dialog which is analogous to Create New Connection dialog will appear.

Drop method
You can choose one of these methods:

  • Send Disconnect message to MQTT server : if this option is selected the plugin will send DISCONNECT packet to the MQTT server and then close the network connection (normal behavior)
  • Close network connection: if this option is selected the plugin won’t send DISCONNECT packet, it will only close the network connection (This behavior simulates some network or client related problems. It is expected that the MQTT server will publish the Will Message if it was specified for the connection in this case)
     

Compatibility with the previous version of the plugin

The plugin is able to play the test cases which were created with the earlier plugin version. The previous version of the plugin stored the connection information for every test step individually so you had to duplicate it in every test step or use property expansions. The connection information will be available in the Connection combo-box as "Individual (legacy) connection" item, and this item is accessible only in this single step. In order to use new features you may have to switch to the new connection management model.  You can use Convert Connection button for this transfer:



This button appears only in editors of test steps which were created by the old version of the plugin. Pressing this button you are able to create a new style connection with the same parameters (Note that the Convert Legacy Connection dialog, which is analogous to the Create New Connection subscribed above, at the same time appears, so you can still correct the values. For instance, if you used property expansions at the test step/test case/test suite level you need to correct them to actual values of project level property expansions). Then you have to choose the connection just created in other legacy test steps which should use the same connection.