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: Gealber Morales via curl-library <curl-library_at_cool.haxx.se>
Date: Mon, 24 May 2021 16:14:53 -0400
Thanks Dan very helpful all the comments.
El lun., 24 de may. de 2021 3:39 p.m., Dan Fandrich via curl-library <
curl-library_at_cool.haxx.se> escribió:
> 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
-------------------------------------------------------------------
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 16:14:53 -0400
Thanks Dan very helpful all the comments.
El lun., 24 de may. de 2021 3:39 p.m., Dan Fandrich via curl-library <
curl-library_at_cool.haxx.se> escribió:
> 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
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-05-24