Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Test cases MQTT
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-library <curl-library_at_cool.haxx.se>
Date: Mon, 24 May 2021 12:36:14 -0700
On Mon, May 24, 2021 at 02:59:00PM -0400, Gealber Morales via curl-library wrote:
> 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
Received on 2021-05-24
Date: Mon, 24 May 2021 12:36:14 -0700
On Mon, May 24, 2021 at 02:59:00PM -0400, Gealber Morales via curl-library wrote:
> 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
Received on 2021-05-24