Thanks. The Web server aspect of things is pretty minimal. I get ics Files from a server then process them in different ways. I do need to make sure I can fetch the file, but beyond that, all the processing is postprocessing. The config file for the app specifies ics URLs. I could mess around and make it accept files, but it's not as clean as `request.get(...)`. I'll figure things out.
On Sun, Jun 22, 2025, 15:52 David Zaslavsky <diaz...@ellipsix.net> wrote: > 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
