Receive MQTT Message Test Step

Applies to ReadyAPI 3.56, last modified on November 21, 2024

About Receive MQTT Message test step

Use this test step to simulate actions of an MQTT client. The test step subscribes to a topic on a broker and receives messages from the broker.

Editing Receive MQTT Message test step

You can modify settings of the test step in its editor:

MQTT Testing: Receive test step

Click the image to enlarge it.

Connection to MQTT server

Connection

Choose a configured connection to the broker from the drop-down list, or select <New Connection...> to create a new connection. Click the Configure button to customize properties of the selected connection in the Configure Connection dialog.

Subscription settings

Subscribed topics

One or more topics of the test step to listen to. Only messages sent to these topics will be received by ReadyAPI. You can specify topics or topic filters. For information on topic filters, see the description of the MQTT standard.

Enter a topic per line. ReadyAPI does not support multiline topic names.

On unexpected topic

This setting specifies how the test step handles messages to which it is not subscribed:

  • Discard – Remove all inappropriate messages until the appropriate message is received. Messages will no longer be available later.

  • Ignore – Save inappropriate messages. These messages can be later analyzed.

  • Fail – Mark this test step as failed if an inappropriate message is received.

Quality of service

Choose the maximum Quality of Service (QoS) to which you subscribe. Messages published at a higher QoS will be received using the QoS specified here. Messages published at a lower QoS will be received at the QoS they were published at.

For example, a client subscribes to a topic with QoS 1. Messages with QoS 0 will be delivered to the client with QoS 0, and messages with QoS 1 or QoS 2 will be delivered with QoS 1.

Available values:

Value Description
At most once (0) The broker sends the message once and does not check whether the subscriber received the message. As a result, the subscriber may or may not receive the message.
At least once (1) The broker keeps sending the message until the subscriber acknowledges that it has received the message. As a result, the subscriber can receive the same message more than once.
Exactly once (2) The broker makes sure that the message was received and that it was received only once.

Expected message type

Select what data type the test step will expect to receive. If a message has a different data type, the test step will fail. Available values include --

  • UTF-8

  • UTF-16

  • Integer number

  • Float number

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

Timeout

Specify how long ReadyAPI waits for the message from the MQTT broker. If there is no message after the timeout expires, the test step fails.

Received message

Topic

The topic of the received message.

Message

The message received.

Configure connection dialog

Use the Configure Connection dialog to configure connections used by the test step. You use the same dialog to create a new connection or to update the connection from a legacy version.

The General tab

MQTT Testing in ReadyAPI: Configure connection dialog
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 used to identify a connection.

Server URL

The MQTT server's URL.

The URL should contain tcp:// when connecting to a TCP socket or ssl:// when connecting to an SSL socket.

The URL may also contain a port number. If the port is not specified, ReadyAPI will use port 1883 for TCP URLs, and 8883 for SSL URLs.

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 empty, a unique client identifier will be generated for every test case run.

Clean Session

Select this check box to create a new connection each time you run the test. If this check box is clear, ReadyAPI and the tested MQTT server will store the session state to enable reliable messaging across several connections. For example, if the connection is lost during the test case run, the Receive MQTT Message test step will still catch messages if it can reconnect.

Authentication

MQTT Testing in ReadyAPI: SSL Properties

Enable the check box if the MQTT server requires authentication.

Login

The user name for connecting to the MQTT server.

Password

The user password for connecting to the MQTT server.

Will message

MQTT Testing in ReadyAPI: SSL Properties

If you enable storing Will messages on the MQTT server, this message will be send to listeners if the "publisher" client disconnects from the server without sending the Disconnect message.

Topic

Enter the message topic. Only clients subscribed to this topic will receive a message published by this test step.

Message type

Select the message encoding. Available values include --

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

Notes:

  • If the JSON or XML message type is selected, the messages are sent as UTF-8 text.

  • Numeric messages are always sent as binary data.

Message

The contents of the message.

Quality of Service

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

Value Description
At most once (0) The sender does not check whether the message was received.
At least once (1) The sender makes sure that the message was received at least once, but does not check whether it was delivered more than once.
Exactly once (2) The sender makes sure that the message was received only once.

Retained

If selected, the Will message will be a retained message: it will be stored on the broker and sent to all new clients subscribing to the topic.

SSL properties

MQTT Testing in ReadyAPI: SSL Properties

CA certificate

Specifies a fully-qualified path to the certificate of the certificate authority (CA) that signed the server certificate.

Client certificate

Specifies a fully-qualified path to a certificate that will be used to sign messages.

Key file

Specifies a fully-qualified path to the client’s private key.

Key password

The password from the specified key file.

SSL server name

The server to which you want to connect. Typically, it is the same as Server URL.

Note: You can connect by specifying the CA certificate without filling in the other parameters.

Property list

Besides the test step editor, you can adjust the test step’s behavior by using its properties in the Properties and Custom Receive MQTT Message Test Step Properties panels in the Navigator.

Name Description
Name

The test step’s name.
Description

Text describing the test step.

Values on the Custom Receive MQTT Message Test Step Properties tab are available to other test steps in your project. For instance, you can verify these property values with the Assertion test step, or check them and change the execution flow with the Conditional GoTo test step.

You can load values of custom properties from a file, or save them to a file. To learn more, see About Properties.

This tab contains the following properties that provide access to the request and response data:

Name Description
ReceivedMessageTopic

The topic of the received message.
ServerURI

Specifies the MQTT server’s URL with the used protocols.

Note: Corresponds to the ServerURL option specified on the General tab of the connection settings.
Timeout

Specifies how long ReadyAPI waits for the message from the MQTT broker (in milliseconds).

Note: Corresponds to the Timeout option in the test step editor.
CertKeyPEM

Specifies the fully-qualified path to the client key file.

Note: Corresponds to the Key file option specified on the SSL Settings tab of the connection settings.
CertSniServer

Specifies the host name of the server, to which you want to connect.

Note: Corresponds to the Server host name option specified on the SSL Settings tab of the connection settings.
Login

The user name for connecting to the MQTT server.

Note: Corresponds to the Login option specified on the Authentication page of the connection settings.
ReceivedMessage

The message received.

Note: Corresponds to the Message option in the test step editor.
CertKeyPassword

Specifies the password for the client’s private key file.

Note: Corresponds to the Key password option specified on the SSL Settings tab of the connection settings.
CertCAPEM

Specifies the fully-qualified path to the CA certificate that was used to sign the server certificate.

Note: Corresponds to the CA certificate option specified on the SSL Settings tab of the connection settings.
QoS

Specifies the maximum quality of the service (QoS) to which you subscribe. Possible values:

  • 0 – At most once

  • 1 – At least once

  • 2 – Exactly once

Note: Corresponds to the Quality of Service option in the test step editor.
ListenedTopics

One or more topics of the test step to listen to.

Note: Corresponds to the Subscribed topics option in the test step editor.
ClientID

The client identifier is used by the server to identify a client.

Note: Corresponds to the ClientID option specified on the General page of the connection settings.
CertClientPEM

Specifies the fully-qualified path to the client’s certificate that will be used to sign messages.

Note: Corresponds to the CA certificate option specified on the SSL Settings tab of the connection settings.
Password

The user password for connecting to the MQTT server.

Note: Corresponds to the Password option specified on the Authentication page of the connection settings.

Verifying response

Use assertions to verify the server response. To add, change or modify them, use the Assertions panel. The test step supports the following assertions:

Name Description
Property Content:
Contains Verifies that the message contains the specified string.
Equals Verifies that the value of a property is equal to the specified value.
Equals (Binary) Checks whether the binary message is equal to a file.
Message Content Assertion Verifies that the message contains expected contents.
Not Contains Verifies that the message does not contain the specified value
Smart Assertion Verifies the message content and metadata such as headers.
XPath Match Checks whether the result of the specified XPath expression is equal to the specified value.
XQuery Match Verifies that the result of the specified XQuery expression is equal to the specified value.
Compliance, Status and Standards
HTTP Header Equals Checks whether the message contains the expected value of an HTTP header.
HTTP Header Exists Verifies that message contains the specified HTTP header.
Swagger Compliance Assertion Verifies that a message is compliant with an OpenAPI or Swagger specification.
Script
Script Assertion Executes a script to perform a custom assertion.
SLA
Response SLA Checks whether the message was received within the specified timeout.

Logging

While the test step editor is open, brief information on received messages is listed in the Log panel. If the test step is run as part of a test case, you can see a more detailed log in the Transaction Log panel.

See Also

About IoT MQTT Testing
MQTT Testing Tutorial
Publish Using MQTT Test Step
Drop MQTT Connection Test Step
Test Steps

Highlight search results