[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avo
From: |
Maxime Devos |
Subject: |
[bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports, |
Date: |
Sat, 22 Jan 2022 19:55:30 +0100 |
User-agent: |
Evolution 3.38.3-1 |
Hi,
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.
> 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.
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.
That is, the same model can be used for searches (either
sorted by score or download), for requesting a description of a
ContentDB ‘package’ and for requesting a specific release of a
package.
Furthermore, the space of resources is even infinite (due to the
search API).
In principle, that procedure could be modified to accept a few
arguments specifying what things will be asked and with
which parameters, but doing that and figuring out the arguments
for each test would be rather tedious.
Aside from verifying that no more traffic than strictly necessary
happens (which would be a nice property but not really required),
I don't see the point of verifying which resources exactly are
queried.
Furthermore, which resources precisely are queried and how often,
seems more of an implementation detail to me. I would rather
focus on the end result: verifying that the imported package
definition is what is expected.
Most tests in tests/minetest.scm are like that: they tell
call-with-packages to create a ContentDB model with some data
(using make-package-json etc.) ask (guix import minetest) to
import some package from the model and compare the result with a
prediction (make-package-sexp) (can this called integration
testing?).
These tests do not care how (guix import minetest) works -- they
don't care about which resources are queried. Instead, they
simply test that the end result (the package definition) is as
predicted.
While criterium (b) might suffice for various unit tests
(e.g. in tests/lint.scm), it is rather impractical and limiting
for the kind of tests that tests/minetest.scm does.
OTOH, criterium (a) not only suffices for tests/lint.scm-style tests,
but also for tests/minetest.scm-style tests. It seems to work
everywhere, except for the single exception tests/challenge.scm.
> It would be nice if we could keep it that way.
Compare (a) and (b), then I think it will be easy to infer what I would
prefer 😉.
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part
- [bug#53389] [PATCH 1/9] tests: Support arbitrary HTTP request handlers., (continued)
- [bug#53389] [PATCH 1/9] tests: Support arbitrary HTTP request handlers., Maxime Devos, 2022/01/20
- [bug#53389] [PATCH 2/9] tests: Generalise %local-url., Maxime Devos, 2022/01/20
- [bug#53389] [PATCH 3/9] tests/minetest: Run a HTTP server instead of mocking., Maxime Devos, 2022/01/20
- [bug#53389] [PATCH 8/9] tests/cpan: Verify URIs., Maxime Devos, 2022/01/20
- [bug#53389] [PATCH 5/9] tests/cpan: Do not hard code a HTTP port., Maxime Devos, 2022/01/20
- [bug#53389] [PATCH 6/9] tests/lint: Do not assume the next port is free., Maxime Devos, 2022/01/20
- [bug#53389] [PATCH 7/9] tests: Allow checking the URI of a HTTP request., Maxime Devos, 2022/01/20
- [bug#53389] [PATCH 9/9] tests/challenge: Do not hard code HTTP ports., Maxime Devos, 2022/01/20
- [bug#53389] [PATCH 4/9] tests/import-github: Run a HTTP server instead of mocking., Maxime Devos, 2022/01/20
- [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports,, Ludovic Courtès, 2022/01/22
- [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports,,
Maxime Devos <=
- [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports,, Ludovic Courtès, 2022/01/25
- [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports,, Maxime Devos, 2022/01/25
- [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports,, Maxime Devos, 2022/01/22
- [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports,, Maxime Devos, 2022/01/22
- [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports,, Maxime Devos, 2022/01/22
- [bug#53389] [PATCH 1/9] tests: Support arbitrary HTTP request handlers., Maxime Devos, 2022/01/22
[bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports,, Ludovic Courtès, 2022/01/20