unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxime Devos <maximedevos@telenet.be>
Cc: 53389@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	[thread overview]
Message-ID: <87wniop7wh.fsf@gnu.org> (raw)
In-Reply-To: <687d96c300852e684422de877cd87769daae7ccd.camel@telenet.be> (Maxime Devos's message of "Sat, 22 Jan 2022 19:55:30 +0100")

Hi,

Maxime Devos <maximedevos@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’.




  reply	other threads:[~2022-01-25  8:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-20 12:59 [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports, Maxime Devos
2022-01-20 13:08 ` [bug#53389] [PATCH 1/9] tests: Support arbitrary HTTP request handlers Maxime Devos
2022-01-20 13:08   ` [bug#53389] [PATCH 2/9] tests: Generalise %local-url Maxime Devos
2022-01-20 13:08   ` [bug#53389] [PATCH 3/9] tests/minetest: Run a HTTP server instead of mocking Maxime Devos
2022-01-20 13:08   ` [bug#53389] [PATCH 4/9] tests/import-github: " Maxime Devos
2022-01-20 13:08   ` [bug#53389] [PATCH 5/9] tests/cpan: Do not hard code a HTTP port Maxime Devos
2022-01-20 13:08   ` [bug#53389] [PATCH 6/9] tests/lint: Do not assume the next port is free Maxime Devos
2022-01-20 13:08   ` [bug#53389] [PATCH 7/9] tests: Allow checking the URI of a HTTP request Maxime Devos
2022-01-20 13:08   ` [bug#53389] [PATCH 8/9] tests/cpan: Verify URIs Maxime Devos
2022-01-20 13:08   ` [bug#53389] [PATCH 9/9] tests/challenge: Do not hard code HTTP ports Maxime Devos
2022-01-22 16:48   ` [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports, Ludovic Courtès
2022-01-22 18:55     ` Maxime Devos
2022-01-25  7:54       ` Ludovic Courtès [this message]
2022-01-25 13:37         ` Maxime Devos
2022-02-07  9:53       ` Ludovic Courtès
2022-02-07 10:59         ` Maxime Devos
2022-03-06 16:23           ` Ludovic Courtès
2022-03-07  7:00             ` Maxime Devos
2022-01-22 19:21     ` Maxime Devos
2022-01-22 19:57     ` Maxime Devos
2022-01-22 20:42     ` Maxime Devos
2022-01-22 18:08   ` [bug#53389] [PATCH 1/9] tests: Support arbitrary HTTP request handlers Maxime Devos
2022-01-20 15:11 ` [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports, Ludovic Courtès
2022-04-12 19:46 ` [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server Maxime Devos
2022-04-21 15:20 ` [bug#53389] [PATCH v2 0/25] Replace some mocking with with-http-server*, avoid harcoding ports Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wniop7wh.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=53389@debbugs.gnu.org \
    --cc=maximedevos@telenet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).