No, you didn't miss anything. The typical use case for plugins like this is
that the responses would be very short and defined in the test code itself; for
example, here's a test of pytest-httpserver itself where the response is just
"OK":
https://github.com/csernazs/pytest-httpserver/blob/master/tests/test_matcher.py.
It wouldn't be worth putting that in a file.
If you wanted to store the response for some particular test query in a file,
you could load the file content yourself and give that as the response to the
server, like this:
expected_response = pathlib.Path("response.txt").read_text()
httpserver.expect(matcher).respond_with_data(expected_response)
Or if you really wanted a server that will serve arbitrary files based on the
requested path, you could implement that with a custom handler
(https://pytest-httpserver.readthedocs.io/en/latest/howto.html#using-custom-request-handler).
But that would be a pretty odd thing to do in tests, because ideally in your
tests you (should) know in advance exactly which requests need to be handled
and what their responses should be. There shouldn't be any need to have the
server figure out on the fly what it needs to serve, as with a real live web
server. (And in fact, it's generally valuable to check that the code being
tested doesn't make any HTTP requests other than the ones it's specifically
supposed to, which you couldn't do as well if you made your server handle
arbitrary requests by serving from the filesystem.)
David
On Sunday, June 22nd, 2025 at 12:46 PM, Skip Montanaro
<skip.montan...@gmail.com> wrote:
> Thanks. Plugins (of all stripes, not just pytest) have always seemed a bit
> magical to me. I see nothing in the docs which offer a way to serve test
> files from a directory, similar to the `-d` flag you can offer to `python -m
> http.server`. Did I miss something?
>
> Skip
>
> On Fri, Jun 20, 2025 at 3:51 PM David Zaslavsky <diaz...@ellipsix.net> wrote:
>
>> There are some pytest plugins that will handle this for you. In particular
>> pytest-httpserver is implemented the way you want, where it'll start the
>> server once at the beginning of your test session and keep it running. I'd
>> suggest checking that out.
>>
>> Though in general, I think it's better not to worry too much about whether
>> resources are allocated freshly for each test or not, unless you find that
>> your test suite is unacceptably slow because of that resource allocation.
>> It's all too easy to have different tests interfere with each other if you
>> reuse resources, unless you're very careful.
>>
>> David
>>
>> -------- Original Message --------
>> On 6/20/25 6:31 AM, Skip Montanaro via code-quality wrote:
>>
>>> I'm struggling trying to understand how Pytest's fixtures can be used to
>>> facilitate setup and teardown of long-running resource servers. For
>>> example, I want to fire up a little web server (because the tool I'm
>>> testing queries a web server IRL) to serve up some simple content. I don't
>>> want to start it for each test case, just once and the start, then stop it
>>> at the end. All the notes/documentation I've found seem to emphasize
>>> fixture's ease-of-use by "requesting" them on a per-test-case basis.
>>>
>>> Can someone point me to a tutorial which explains how to properly set up
>>> and tear down a service at the beginning and end of a test run?
>>>
>>> Thx,
>>>
>>> Skip_______________________________________________
code-quality mailing list -- code-quality@python.org
To unsubscribe send an email to code-quality-le...@python.org
https://mail.python.org/mailman3//lists/code-quality.python.org
Member address: arch...@mail-archive.com
