User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
There is a regular 'Virtual IoT' meetup, which I think that
Frédéric Desbiens schedules. Perhaps it could be one of those? I
realise it could still be a small number of participants, but
could reach people who wouldn't otherwise know of the project's
existence.
Ian
On 18/12/2019 13:07, Alexander Kaiser
wrote:
Hi Ben,
everyone interested is very welcome to participate. I'll
consult with the Project Leads and send around a Doodle here.
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.
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?