Yeah, I realize the structure isn't correct right now. I will probably be refactoring things a bit. (Still, it's just a small script. I'm mostly trying to learn how pytest's fixtures work.)
S On Sun, Jun 22, 2025 at 6:58 PM Bassam Khouri <bassam.kho...@gmail.com> wrote: > 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
