Test cases MQTT

[Gealber Morales via curl-library]

Hello again,
I managed to make one test case, but it's more an imitation of other tests
than a proper understanding. I will share here part of the doubts that I
have right now, I've been reading also curl test suite file format
<https://curl.se/dev/test-fileformat.html> to clarify some of these doubts,
here I go:

1. What is the main flow that follows when I run for example *./runtests.pl
<http://runtests.pl> 3017? *I don't know Perl so don't quite understand
this 6000 lines program, until now *runtests.pl <http://runtests.pl>* is
magic to me. I think that it must read the configuration from the test case
that I specified, in this case *3017, *and supply part of that
configuration to the *server/mqttd.c *program, which I could understand
mostly.

2. The tag *<reply></reply> *contains the data to be sent to the client on
its request, according to curl test suite file format
<https://curl.se/dev/test-fileformat.html>. For example, in my test case:












*<reply><data nocheck="yes">hello</data><datacheck hex="yes">00 04 31 31 39
30 68 65 6c 6c 6f 5b 4c 46 5d 0a</datacheck># error 5 - "Connection
Refused, not authorized"<servercmd>error-CONNACK 5</servercmd></reply>*

Here I'm telling, in response to the client request, which I don't know
right now, I will send you this *data* and a *CONNACK *packet with error 5.
Which correspond to not authorized, given MQTT v3.1.1.

Is that correct?

3. Now comes the client part. The tag *<command></command>* in my case is:


*<command
option="binary-trace">mqtt://%HOSTIP:%MQTTPORT/%TESTNUMBER</command>*

What I could figure out here, is that this seems to be equivalent to
*curl mqtt://localhost:1883/3017*
of course, I changed *localhost:1883* for *%HOSTIP:%MQTTPORT*

So in case I would like to test *curl -u testuser:testpass
mqtt://localhost:1883/3017, *shoud I just add the *-u testuser:testpass ?? *

* Until now the flow is seems to be as follows:*
1. server will have to return me error 5 in the *CONNACK packet in
response to this client request. Right?*

Well here comes the main point of my doubts, what does the *<verify></verify>
tag? *Reading the name seems pretty clear, but look at this:

















*<verify># These are hexadecimal protocol dumps from the client## Strip out
the random part of the client id from the CONNECT message# before
comparison<strippart>s/^(.*
00044d5154540402003c000c6375726c).*/$1/</strippart><protocol>client CONNECT
18 00044d5154540402003c000c6375726cserver CONNACK 2 20020005</protocol># 8
is CURLE_WEIRD_SERVER_REPLY<errorcode>8</errorcode></verify>*

I admit it, the comments give you a clue, but why should I for example
strip the *client ID* from the *CONNECT message?*
Or more important, what does the *<protocol></protocol> tag? *I think it's
defining the flow between the server and the client, but don't understand
for example
this --> *client CONNECT 18 00044d5154540402003c000c6375726c*

*what is 18 for?* Is this parsed and sent to *server/mqttd.c*?

Any resource or advice that you can share is welcome.

Greetings

[Dan Fandrich via curl-library]

1. What is the main flow that follows when I run for example ./runtests.pl
3017? I don't know Perl so don't quite understand this 6000 lines program,
until now runtests.pl is magic to me. I think that it must read the
configuration from the test case that I specified, in this case 3017, and
supply part of that configuration to the server/mqttd.c program, which I could
understand mostly. 

Most of what you're asking about the test suite is documented in
tests/FILEFORMAT.md. Hopefully, you won't need to read runtests.pl to figure it
out, unless you're extending the test suite itself. I'll add a few other
comments below.

<servercmd>
error-CONNACK 5
</servercmd>
</reply>
Here I'm telling, in response to the client request, which I don't know right
now, I will send you this data and a CONNACK packet with error 5. Which
correspond to not authorized, given MQTT v3.1.1.

The servercmd section is read by the MQTT test server and configures it for the
test. If the server doesn't already do whatever it is you need it to do for
this test, then you'll have to extend the server and have it parse a new
command in this section.

So in case I would like to test curl -u testuser:testpass mqtt://localhost:1883
/3017, shoud I just add the -u testuser:testpass ?? 

You'll probably want at least two tests here, one succeeding and one with an
invalid user/password to test the error case. But in general, yes, this is how
you'd do it. You can see many other authentication tests setting -u.

I admit it, the comments give you a clue, but why should I for example strip
the client ID from the CONNECT message?

Data fields that can change from test to test need to be removed or
canonicalized so that the comparison with the golden data will succeed. This is
often things based on random numbers or time stamps, although there is also
provision in the test suite to make random numbers not-so-random and make time
stamps fixed to get around this. The less you need to strip, the better is your
test coverage.

Dan
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: h

[Gealber Morales via curl-library]

Thanks Dan very helpful all the comments.

El lun., 24 de may. de 2021 3:39 p.m., Dan Fandrich via curl-library <

Post by Gealber Morales via curl-library

1. What is the main flow that follows when I run for example ./

runtests.pl

3017? I don't know Perl so don't quite understand this 6000 lines

program,

until now runtests.pl is magic to me. I think that it must read the
configuration from the test case that I specified, in this case 3017, and
supply part of that configuration to the server/mqttd.c program, which I

could

understand mostly.

Most of what you're asking about the test suite is documented in
tests/FILEFORMAT.md. Hopefully, you won't need to read runtests.pl to figure it
out, unless you're extending the test suite itself. I'll add a few other
comments below.

<servercmd>
error-CONNACK 5
</servercmd>
</reply>
Here I'm telling, in response to the client request, which I don't know

right

now, I will send you this data and a CONNACK packet with error 5. Which
correspond to not authorized, given MQTT v3.1.1.

The servercmd section is read by the MQTT test server and configures it for the
test. If the server doesn't already do whatever it is you need it to do for
this test, then you'll have to extend the server and have it parse a new
command in this section.

So in case I would like to test curl -u testuser:testpass

mqtt://localhost:1883

/3017, shoud I just add the -u testuser:testpass ??

You'll probably want at least two tests here, one succeeding and one with an
invalid user/password to test the error case. But in general, yes, this is how
you'd do it. You can see many other authentication tests setting -u.

I admit it, the comments give you a clue, but why should I for example

strip

the client ID from the CONNECT message?

Data fields that can change from test to test need to be removed or
canonicalized so that the comparison with the golden data will succeed. This is
often things based on random numbers or time stamps, although there is also
provision in the test suite to make random numbers not-so-random and make time
stamps fixed to get around this. The less you need to strip, the better is your
test coverage.
Dan
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html