Jump to: navigation, search

Difference between revisions of "Paho/MQTT Interop Testing Day"

(Participants)
Line 52: Line 52:
  
 
* Ian Craggs, IBM, Paho Project, [http://www.eclipse.org/paho/ www.eclipse.org/paho/]
 
* Ian Craggs, IBM, Paho Project, [http://www.eclipse.org/paho/ www.eclipse.org/paho/]
 +
 +
 +
==Test Code Collection==
 +
* [[File:Mqtt-test.zip]]

Revision as of 17:40, 12 November 2013

We will be hosting an MQTT Interop Testing Day on Monday, March 17, 2014 in Burlingame, CA. The goal is to have as many different MQTT client and server implementations participate in interoperability testing to validate the implementation of the upcoming OASIS MQTT standard.

Date and Location

Monday, March 17
9:00am-5:00pm
Hyatt Regency San Francisco Airport (same place at EclipseCon 2014)

Agenda

TBD

Testing Plans

My starting point for a plan for testing.

1) We need tests for both MQTT client libraries and servers. Servers may also act as clients connecting to other servers (called a bridge in Mosquitto/RSMB).

2) The MQTT OASIS specification is nearing a public consultation draft. It will contain normative statements which will be listed, and the various degrees of compliance required categorized as in RFC 2119.

"The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119."

3) I propose we take each of the listed normative statements and turn them into one or two test cases, with a link back to the specification. Each statement will apply to either server or client library, some to both. Each test case will test either client library or server and will consist of input sequences along with assertions about the results that should/must be observed.

4) Server tests can be described at the MQTT packet level. I already have some tests which do this - so does Roger. Each of the server tests will be a sequence of MQTT flows into a server, interleaved with the expected MQTT packets out of the server.

5) Because the interfaces used to drive client libraries are all different, the client tests will need to be more abstract. They could also be termed in MQTT packet flows, in this sort of way "make calls to the client library to cause MQTT packet flows foo", "following packet flow bar, make a message available to the application", and so forth. Using these test scenarios, any client library can be tested against any server.

6) Server bridge tests will be similar to client tests - probably a subset as bridges have more limited scope for behaviour in general.

7) On the day, servers would be expected to be configured in a standard way to allow the client tests to work against them. We'll publish that configuration as part of the client tests.

8) We will have at least one Mosquitto instance available for anyone to test against on the day. We expect to have Mosquitto updated to allow OASIS conforming clients to connect.

9) Other aspects, which may not be in the specification directly, that we might like tests for: SSL/TLS connections, High Availability client library support.

Ian Craggs

Organizers

  • Ian Craggs, IBM
  • Ian Skerrett, Eclipse Foundation

Planning Meeting Minutes

Participants

Name, Company, Product/Project, Product/Project URL


Test Code Collection