Pytest fixtures for setup/teardown
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
I do similar things in my test code. I create a session fixture so that it survives the entire pytest session. Something like: @pytest.fixture(scope="session", autouse=True) def webserver(): start_webserver_here() yield {"url": "the URL here"} stop_webserver_here() I put a more comprehensive example in a gist: https://gist.github.com/dstanek/326bc12ed3315d5c84aa80beb90fc5e8. On Fri, Jun 20, 2025 at 9:31 AM Skip Montanaro via code-quality < code-quality@python.org> 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-leave@python.org https://mail.python.org/mailman3//lists/code-quality.python.org Member address: dstanek@dstanek.com
-- david stanek web: https://dstanek.com twitter: https://twitter.com/dstanek linkedin: https://www.linkedin.com/in/dstanek/
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
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 <diazona@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
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.... 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-r...). 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.montanaro@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 <diazona@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
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 <diazona@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.... 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-r...). 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.montanaro@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 <diazona@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
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 <diazona@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.... 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-r...). 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.montanaro@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 <diazona@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-leave@python.org https://mail.python.org/mailman3//lists/code-quality.python.org Member address: bassam.khouri@gmail.com
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.khouri@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 <diazona@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.... 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-r...). 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.montanaro@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 <diazona@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-leave@python.org https://mail.python.org/mailman3//lists/code-quality.python.org Member address: bassam.khouri@gmail.com
participants (4)
-
Bassam Khouri -
David Stanek -
David Zaslavsky -
Skip Montanaro