Comments (14)
You can check the log
attribute of the httpserver object. This contains all the request - response pairs (in a 2-element tuple) which were processed.
If that's empty, it means that no requests have been made:
def test_norequests(httpserver):
# code which may have made requests or not
assert len(httpserver.log) > 0, "At least one request should be made"
or:
def test_norequests(httpserver):
# code which may have made requests or not
assert httpserver.log, "At least one request should be made"
from pytest-httpserver.
I'll point to re-using the RequestMatcher code. I hear you, in that the string representation could be overly long, but I think that's ok.
I know that I'm using request matchers where the only difference is a single query string parameter, and I would want to be able to detect that difference when I'm looking at a list of leftover request handlers.
Also, I think it would be less effort to have the RequestHandler __repr__
stringify, at least it's matcher property, in the same manner as other __repr__
methods (ie, the RequestMatcher one above), (which would then implicitly delegate to RequestMatcher.__repr__
).
from pytest-httpserver.
Thanks @csernazs. You are awesome 👍
from pytest-httpserver.
Is it good idea to have some method like expect_no_requeast
on httpserver
?
from pytest-httpserver.
If this function is useful for you, you can implement it in conftest.py or at other places, so it will be available.
Personally, I think checking that there was at least one http request made is error prone, as it does not say anything about what kind of http request was made (provided you have more than one handlers), and the original idea of this library was to check the client code by asserting to some value which is known only to the server.
Eg:
def test_expected_request_json(httpserver: HTTPServer):
httpserver.expect_request("/foobar").respond_with_json({"foo": "bar"})
assert requests.get(httpserver.url_for("/foobar")).json() == {'foo': 'bar'}
Here, the client (which is the requests library in this case) should return the {"foo": "bar"}" dict, and this dict is only known to the server. So we can be entirely sure that the client made a http request by checking the data it returned. If by some accident the
requests` was written in a way that it would return the dictionary in question without making any requests, then the test should be adjusted to avoid this situation by using different data.
from pytest-httpserver.
I can understand the case for at least one request made. I'm talking about a case where I want to assert that given set of conditions I want httpserver
to receive no requests at all. I can certainly add that case in conftest.py
but if the package itself has some good way to tell that no requests received
from pytest-httpserver.
I see.
This is the default. If you have no handlers and your client makes any request, then it is an error.
You need to call the check_assertions()
method at the end, this will raise AssertionError.
def test_expected_request_json(httpserver):
### httpserver.expect_request("/foobar").respond_with_json({"foo": "bar"})
requests.get(httpserver.url_for("/foobar")) # this will get http status 500 describing the issue
httpserver.check_assertions()
from pytest-httpserver.
Thanks @csernazs
from pytest-httpserver.
Should expect_oneshot_request()
expect that precisely one request was made to it? I was expecting that. Of course it's fine to add assert len(httpserver.log) == 1
. But yeah, I was kind of surprised that it's not the default to error out if a oneshot handler didn't see a request.
from pytest-httpserver.
Yes, that's a good question. Originally it was implemented to ensure that the client is doing no more than a single request to that endpoint. It is similar to the ordered handlers except the order does not matter for the oneshot.
If I was implementing this from zero, probably consider any leftover oneshot (and ordered) handlers as an error, but now it is a change which would break the tests already using this.
You can also check for the leftover handlers: ordered_handlers
and oneshot_handlers
attributes containing the handlers and once the handler is used it will be removed from these.
If it would make your life easier a new method can be added to httpserver to check these.
from pytest-httpserver.
Hi @csernazs, (Thanks for pytest-httpserver 👍)
I found this looking for how to check for unused handlers, and assert httpserver.ordered_handlers == []
and/or assert httpserver.oneshot_handlers == []
does the job quite nicely for me.
I'm butting into the conversation to say that what would make life easier for me would be a RequestHandler
representation, (probably just dispatching to the the RequestHandler.matcher (RequestMatcher)
repr).
I think this would make it easier for me to see where the expected/actual requests diverged.
Currently the pytest output only lets me know the number of leftover request handlers.
> assert httpserver.oneshot_handlers == []
E assert [<pytest_httpserver.httpserver.RequestHandler object at 0x000001F46F9765D0>] == []
E Left contains one more item: <pytest_httpserver.httpserver.RequestHandler object at 0x000001F46F9765D0>
E Full diff:
E - []
E + [<pytest_httpserver.httpserver.RequestHandler object at 0x000001F46F9765D0>]
from pytest-httpserver.
hi @GKTheOne ,
I think this is a very good idea. We just need to decide what to include to the __repr__
.
Something like that:
<RequestHandler GET /foobar>
(so it would be the method and the URI)
We would not include the json or data as it can be arbitrary length. Same for headers and query string, but actually query string could be possibly included.
<RequestHandler GET /foobar?param1=value1¶m2=value2>
Something like this...?
We could optionally include the response status or some other data from the response, but I think we should keep this short and brief (response status code is just "200 OK", that is short, the response body is long).
What do you think?
from pytest-httpserver.
I found that requestmatcher already have a __repr__
defined like this:
pytest-httpserver/pytest_httpserver/httpserver.py
Lines 342 to 353 in e32a568
We could re-use this code, but I think it is way too verbose, especially if you have json or data specified for the matcher.
So we can either re-use this or write a new one which is more brief. What do you think?
from pytest-httpserver.
hi @GKTheOne , #273 has been released with version 1.0.9 to pypi with the additional repr.
from pytest-httpserver.
Related Issues (20)
- Can HTTPServer().handlers be modified from user code? HOT 3
- Recommendations for running both http (non-s) and https test within the same session HOT 2
- header auth matching breaks with Werkzeug>=2.3.0 HOT 5
- `werkzeug.urls` deprecation warnings with Werkzeug 2.3.0 HOT 2
- Twine dependency in 1.0.7 HOT 2
- Waiting without pytest and without starting the server HOT 6
- RFE: please start making github releases HOT 4
- Program stuck on server.stop() HOT 3
- Support Werkzeug 3.0 HOT 2
- Remove `<4` Python version constraint
- Not compatible with werkzeug >= 3.0 HOT 1
- Documentation: a small correction and adding a note for request handler HOT 5
- Add __repr__ to RequestHandler
- Add ability to simulate faults HOT 9
- Add verification for calls recieved HOT 9
- Multiple responses per endpoint HOT 4
- Am I missing something here? Everything seems to require `httpserver.url_for` which breaks everything HOT 3
- Enable using a threaded WSGI server HOT 2
- Project latest code and documentation not aligned with version published on pypy HOT 3
- 1.0.11: `test_verify_assert_msg` and `test_verify_assert_msg_no_similar_requests` fails HOT 15
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pytest-httpserver.