Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Paho Clients Conformance Testing
Hello Ian,

I'm glad to hear that you are interested in test suites for MQTT.

Unfortunately, the installation is sometimes challenging and still not as user-friendly as I'd like it to be. However, we still have some potential for improvement at this point, be it in the process itself or in the documentation.
I would like to demonstrate the IoT-Testware and discuss further steps with you.

Best regards, 
Alexander

On Tue, Dec 17, 2019 at 2:34 PM Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

Hello Alexander,

I am interested in your work.  It has (long) been a goal of mine to generate abstract test suites for MQTT client libraries (and brokers.  Obviously for brokers the MQTT protocol can be used directly but as you point out for client libraries translation into concrete API calls is needed.

Perhaps we could have a video call in January so that you could demonstrate and we could discuss?

(I just tried to follow the Quickstart Guide, and had some failures - it could be me, I don't know yet).

Ian

On 06/12/2019 10:49, Alexander Kaiser wrote:
Hello Paho Enthusiasts,

some of you might already have heard about the Eclipse IoT-Testware[1] project.
Within the IoT-Testware we have also MQTT v3.1.1 Conformance Tests für Brokers and Clients.

However, while testing Brokers is quite straightforward, testing Clients is a bit more challenging. The reason, MQTT Client libraries are required to be triggered by an application. So for conformance testing, we required some sort of a testing application which can trigger the Implementation Under Test (IUT) on behalf of the Test System (TS). Such a testing application can be imagined as remote control (to be precise the receiver of an RC), though we call the concept Upper Tester (UT) which is sketched in the attached (mqtt_client_testing.png) picture.

The IoT-Testware has already the TS side of the UT (the RC itself) and a simple JSON definition for the PCO (Point of Control and Observation)[2], let's imagine this one as the RC protocol.
Well, while the TS is complete from this perspective, we still require RC receivers (UT part on the IUT side).
For testing purposes, I have built UTs for two of the available Paho clients (Java and Python) and looking now for a new home for these components. 

Have you any ideas on how we could manage that and if cooperation between IoT-Testware and Paho would be beneficial? Maybe as an addition to Paho's Interoperability Testing efforts?


Best regards
--
Alexander Kaiser
IoT Researcher


relayr GmbH • Bergmannstraße 102/103 • 10961 Berlin
Managing Directors: Josef Brunner, William Hite
Commercial Register Number: HRB 234794
Tax ID: 37/503/21630, VAT ID: DE288362290

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/paho-dev
-- 
Ian Craggs
Eclipse IoT PMC; Eclipse Paho Project Lead; OASIS MQTT TC Member
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/paho-dev


--
Alexander Kaiser
IoT Researcher


relayr GmbH • Bergmannstraße 102/103 • 10961 Berlin
Managing Directors: Josef Brunner, William Hite
Commercial Register Number: HRB 234794
Tax ID: 37/503/21630, VAT ID: DE288362290

Back to the top