GNU bug report logs - #53389
[PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports,

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 53389 <at> debbugs.gnu.org
Subject: [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports,
Date: Tue, 25 Jan 2022 08:54:38 +0100

Hi,

Maxime Devos <maximedevos <at> telenet.be> skribis:

> Ludovic Courtès schreef op za 22-01-2022 om 17:48 [+0100]:
>> > +        (unless keep-lingering?
>> > +          ;; exit the server thread
>> > +          (system-async-mark (lambda () (throw 'quit)) server))
>> 
>> When do we need ‘keep-lingering?’?
>
> In tests/challenge.scm (call-mismatch-test), due to how the store monad
> work, the thunk technically returns (*) before we are done with the
> querying the server.  Perhaps this can be resolved with sufficient
> monadology, but I don't quite see how.
>
> (*) a monadic value.

Oh I see.

>> So far, all uses of ‘with-http-server’ expected that the server would
>> quit once the last response has been sent.
>
> AFAIK, they don't expect that the server quits. But they don't expect
> that the server does not quit either.  Rather, they need the server
> to keep running as long as needed -- i.e., after the last request
> has been answered.
>
> The only reason that the server quits, is to perform a form of garbage
> collection, to avoid accumulating threads and server ports.

Yes.

> There appear to be two criteria for deciding when to exit the server:
>
>  (a) Exit when the thunk returns. 
>
>      This is similar to 'call-with-port' and 'call-with-output-file'
>      automatically closing the port when the procedure returns.
>      There don't seem to be any drawbacks with this criterium.
>
>  (b) Exit when there are no responses left.
>
>      This is problematic when there is no list of reponses but rather
>      some function mapping requests to responses without any
>      limitations on how often a resource is requested, or when there
>      are multiple resources available and the ‘client’ is allowed to
>      query a proper subset ...
>
>      E.g., the way the tests in tests/minetest.scm are written, the
>      tests don't care in which order resources are accessed and whether
>      a resource is accessed multiple time.  Furthermore, the procedure
>      for creating a testing model of ContentDB (call-with-packages) has
>      no idea what parts of the model will be accessed.

So tests/minetest.scm needs more than pre-programmed responses that are
returned in a specified order?

In ideal black-box testing, sure, you would make the test HTTP server
completely oblivious to what’s being tested, in particular oblivious to
the order in which requests might arrive.

But in practice, you also want to keep the test infrastructure as simple
and concise as possible, or you’ll need tests for that infrastructure
too.  I guess that’s my main concern.

So I would opt for minimal changes.  There are 6 files under tests/ that
mock ‘http-fetch’.  Perhaps we can start converting them one by one to
the (guix tests http) infrastructure as it exists, and only change that
infrastructure when needed?

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.