This calls for software design/architecture for test ability. Ideally, the test would accept the contents of the ICS file, allows you to verify various things, including fault injection. There should be other tests that would run against the a web server to validate and verify the end to end workflow.
Cheers, On Sun, Jun 22, 2025 at 5:18 PM Skip Montanaro via code-quality < code-quality@python.org> wrote: > 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: bassam.kho...@gmail.com >
_______________________________________________ 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
