curl / Mailing Lists / curl-library / Single Mail
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

From: Gealber Morales via curl-library <>
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 <> 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 ./
> > 3017? I don't know Perl so don't quite understand this 6000 lines
> program,
> > until now 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/ Hopefully, you won't need to read 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:
> Etiquette:

Received on 2021-05-24