I am writing unit-tests for my flask application. I have couple of method which not aimed to return response, but it is actively using cookies. For example:
def get_timezone():
try:
return int(request.cookies.get('timezone_offset', 0))
except (RuntimeError, ValueError):
pass
return 0
My test looks like:
from my_main import my_flask_app
with my_flask_app.test_Request_context(**request_environ_params):
tz_value = 4
# HERE. How to setup cookie value to `tz_value`?
tz = myapp.utils.get_timezone()
self.assertEqual(tz, tz_value)
So, I want to setup cookies (how to setup other request parameters I am already figured out) for testing purposes. How it can be done?
The test client has a set_cookie method, does something like this work?
with app.test_client() as c:
c.set_cookie('localhost', 'COOKIE_NAME', 'cookie_value')
resp = c.get('/my_url')
I think this will be useful:
with app.app_context():
with app.test_request_context():
resp = make_response(redirect('your_url'))
resp.set_cookie('Cookie_name', 'Cookie_Value')
I think this can help you.
The cookie should in headers which is a key of **request_environ_params
cookie = http.dump_cookie("Cookie_name",'Cookie_value')
with app.test_request_context(path="/", method="GET", headers={"COOKIE":cookie}):
# do_something...
I think you can know my answer.
:P(I'm not good at English)
Related
I'm unit testing my Flask app.
The code under test is as follows:
#app.route("/my_endpoint/", methods=["GET"])
def say_hello():
"""
Greets the user.
"""
name = request.args.get("name")
return f"Hello {name}"
The test looks like this:
class TestFlaskApp:
def test_my_endpoint(self):
"""
Tests that my endpoint returns the result as plain text.
:return:
"""
client = app.test_client()
response = client.get("/my_endpoint?name=Peter")
assert response.status_code == status.HTTP_200_OK
assert response.data.decode() == "Hello Peter"
The error is:
Expected :200
Actual :308
So instead of "OK" (200) I'm getting a "Permanent Redirect" (308)
If the #app.route ends with a slash you must also use the slash in the test:
Instead of
response = client.get("/my_endpoint?name=Peter")
use
response = client.get("/my_endpoint/?name=Peter")
in your unit test.
It makes sense yet took me too long time to find out.
Flask use werkzeug.routing.Rule, which enable strict_slashes as default, visiting a branch URL without a trailing slash will redirect to the URL with a slash appended. Which cause response with 308 (Permanent Redirect).
So, your request path must be exactly matched with the route path.
If you want to support both routes:
/my_endpoint
/my_endpoint/
Just set app.route with strict_slashes=False, like this:
#app.route('/my_endpoint', methods = ['POST'], strict_slashes=False)
def view_func():
pass
In setting up a ArchiveIndexView in Django I am able to successfully display a list of items in a model by navigating to the page myself.
When going to write the test in pytest to verify navigating to the page "checklist_GTD/archive/" succeeds, the test fails with the message:
> assert response.status_code == 200
E assert 301 == 200
E + where 301 = <HttpResponsePermanentRedirect status_code=301, "text/html; charset=utf-8", url="/checklist_GTD/archive/">.status_code
test_archive.py:4: AssertionError
I understand there is a way to follow the request to get the final status_code. Can someone help me with how this done in pytest-django, similar to this question? The documentation on pytest-django does not have anything on redirects. Thanks.
pytest-django provides both an unauthenticated client and a logged-in admin_client as fixtures. Really simplifies this sort of thing. Assuming for the moment that you're using admin_client because you just want to test the redirect as easily as possible, without having to log in manually:
def test_something(admin_client):
response = admin_client.get(url, follow=True)
assert response.status_code == 200
If you want to log in a standard user:
def test_something(client):
# Create user here, then:
client.login(username="foo", password="bar")
response = client.get(url, follow=True)
assert response.status_code == 200
By using follow=True in either of these, the response.status_code will equal the return code of the page after the redirect, rather than the access to the original URL. Therefore, it should resolve to 200, not 301.
I think it's not documented in pytest-django because the option is inherited from the Django test client it subclasses from (making requests).
UPDATE:
I'm getting downvoted into oblivion but I still think my answer is better so let me explain.
I still think there is a problem with Shacker's answer, where you can set follow=True and get a response code of 200 but not at the URL you expect. For example, you could get redirected unexpectedly to the login page, follow and get a response code of 200.
I understand that I asked a question on how to accomplish something with pytest and the reason I'm getting downvoted is because I provided an answer using Django's built-in TestCase class. However, the correct answer for the test is/was more important to me at the time than exclusively using pytest. As noted below, my answer still works with pytest's test discovery so I think the answer is still valid. After all, pytest is built upon Django's built-in TestCase. And my answer asserts the response code of 200 came from where I expected it to come from.
The best solution would be to modify pytest to include the expected_url as a parameter. If anyone is up for doing this I think it would be a big improvement. Thanks for reading.
ORIGINAL CONTENT:
Answering my own question here. I decided to include final expected URL using the built-in Django testing framework's assertRedirects and verify that it (1) gets redirected initially with 302 response and (2) eventually succeeds with a code 200 at the expected URL.
from django.test import TestCase, Client
def test_pytest_works():
assert 1==1
class Test(TestCase):
def test_redirect(self):
client = Client()
response = client.get("/checklist_GTD/archive/")
self.assertRedirects(response, "/expected_redirect/url", 302, 200)
Hat tip to #tdsymonds for pointing me in the right direction. I appreciated Shacker's answer but I have seen in some scenarios the redirect result being 200 when the page is redirected to an undesirable URL. With the solution above I am able to enforce the redirect URL, which pytest-django does not currently support.
Please note: This answer is compliant with the auto-discover feature of pytest-django and is thus not incompatible (it will auto-discover both pytest-django and Django TestCase tests).
Here is a link to the proto file.
Please can someone help me understand how to make this work:
from django.views.decorators.csrf import csrf_exempt
from bitchikun import payments_pb2
#csrf_exempt
def protoresponse(request):
xpo = payments_pb2.Payment.ParseFromString(request)
t = type(xpo)
xpa = request.PaymentACK
xpa.payment = xpo.SerializeToString()
xpa.memo = u'success'
return HttpResponse(xpa.SerializeToString(), content_type="application/octet-stream")
All input appreciated :)
OK so I think I understand what is happening now. You have a system which is POSTing a serialized protobuf to your Django app, and you need to return another protobuf in response.
In Django, you can access the data from a POST in request.body. That is probably what you need to pass to ParseFromString.
You have some other errors too: you refer to request.PaymentACK, which doesn't exist - you mean payments_pb2.PaymentACK - and you never actually instantiate it. Also, you are trying to pass the serialized version of the original request protobuf to that response one, when you should be passing the actual message.
So, altogether it would look like this:
xpo = payments_pb2.Payment.FromString(request.body)
xpa = payments_pb2.PaymentACK()
xpa.payment = xpo
xpa.memo = u'success'
return HttpResponse(xpa.SerializeToString(), content_type="application/octet-stream")
I am writing some tests in Django to check the apps which I have written. I am more or less working through what is suggested on here (http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/).
However, when I put something like
resp = self.client.get('made_up_url')
self.assertEqual(resp.status_code, 404)
which doesn't exist (and hence I'm hoping for a 404 response, i.e. the test will pass)...but the test fails saying 200!=400, i.e. it seems to think that the made_up_url is a valid page.
Any ideas what could be wrong?
You are trying to self.client.get an unexistent URL: made_up_url. As dan-klasson told you, you need to get /made_up_url.
I suggest that, instead of hardcoding the URL in the self.client.get arguments, first name the related URL in your urls.py file. So you can resolve it via the reverse function.
Then, once you have a name for it, you can do this in your unit tests:
from django.core.urlresolvers import reverse
url = reverse('made_up_url')
resp = self.client.get(url)
self.assertEqual(resp.status_code, 404)
I'm trying to build an URL-alias app which allows the user create aliases for existing url in his website.
I'm trying to do this via middleware, where the request.META['PATH_INFO'] is checked against database records of aliases:
try:
src: request.META['PATH_INFO']
alias = Alias.objects.get(src=src)
view = get_view_for_this_path(request)
return view(request)
except Alias.DoesNotExist:
pass
return None
However, for this to work correctly it is of life-importance that (at least) the PATH_INFO is changed to the destination path.
Now there are some snippets which allow the developer to create testing request objects (http://djangosnippets.org/snippets/963/, http://djangosnippets.org/snippets/2231/), but these state that they are intended for testing purposes.
Of course, it could be that these snippets are fit for usage in a live enviroment, but my knowledge about Django request processing is too undeveloped to assess this.
Instead of the approach you're taking, have you considered the Redirects app?
It won't invisibly alias the path /foo/ to return the view bar(), but it will redirect /foo/ to /bar/
(posted as answer because comments do not seem to support linebreaks or other markup)
Thank for the advice, I have the same feeling regarding modifying request attributes. There must be a reason that the Django manual states that they should be considered read only.
I came up with this middleware:
def process_request(self, request):
try:
obj = A.objects.get(src=request.path_info.rstrip('/')) #The alias record.
view, args, kwargs = resolve_to_func(obj.dst + '/') #Modified http://djangosnippets.org/snippets/2262/
request.path = request.path.replace(request.path_info, obj.dst)
request.path_info = obj.dst
request.META['PATH_INFO'] = obj.dst
request.META['ROUTED_FROM'] = obj.src
request.is_routed = True
return view(request, *args, **kwargs)
except A.DoesNotExist: #No alias for this path
request.is_routed = False
except TypeError: #View does not exist.
pass
return None
But, considering the objections against modifying the requests' attributes, wouldn't it be a better solution to just skip that part, and only add the is_routed and ROUTED_TO (instead of routed from) parts?
Code that relies on the original path could then use that key from META.
Doing this using URLConfs is not possible, because this aliasing is aimed at enabling the end-user to configure his own URLs, with the assumption that the end-user has no access to the codebase or does not know how to write his own URLConf.
Though it would be possible to write a function that converts a user-readable-editable file (XML for example) to valid Django urls, it feels that using database records allows a more dynamic generation of aliases (other objects defining their own aliases).
Sorry to necro-post, but I just found this thread while searching for answers. My solution seems simpler. Maybe a) I'm depending on newer django features or b) I'm missing a pitfall.
I encountered this because there is a bot named "Mediapartners-Google" which is asking for pages with url parameters still encoded as from a naive scrape (or double-encoded depending on how you look at it.) i.e. I have 404s in my log from it that look like:
1.2.3.4 - - [12/Nov/2012:21:23:11 -0800] "GET /article/my-slug-name%3Fpage%3D2 HTTP/1.1" 1209 404 "-" "Mediapartners-Google
Normally I'd just ignore a broken bot, but this one I want to appease because it ought to better target our ads (It's google adsense's bot) resulting in better revenue - if it can see our content. Rumor is it doesn't follow redirects so I wanted to find a solution similar to the original Q. I do not want regular clients accessing pages by these broken urls, so I detect the user-agent. Other applications probably won't do that.
I agree a redirect would normally be the right answer.
My (complete?) solution:
from django.http import QueryDict
from django.core.urlresolvers import NoReverseMatch, resolve
class MediapartnersPatch(object):
def process_request(self, request):
# short-circuit asap
if request.META['HTTP_USER_AGENT'] != 'Mediapartners-Google':
return None
idx = request.path.find('?')
if idx == -1:
return None
oldpath = request.path
newpath = oldpath[0:idx]
try:
url = resolve(newpath)
except NoReverseMatch:
return None
request.path = newpath
request.GET = QueryDict(oldpath[idx+1:])
response = url.func(request, *url.args, **url.kwargs)
response['Link'] = '<%s>; rel="canonical"' % (oldpath,)
return response