Unit tests for API endpoints #396
Comments
|
We probably want to mock JSON responses from GitHub. https://github.com/dropbox/responses looks cool. I'm sure there's lots more out there. |
|
Yes. That's a very good idea and I'll also try to document at the same time (see #397). |
|
In #667 I tested all the error issues. Once the PR is merged they will I guess I can add tests for success. |
|
ok important comment for this issue. I need to describe this at a point. It took me a lot of time to pull out the right strings. There's a partial documentation here but which is "hidden" in the functional tests. ok. Starting to have a clearer picture. |
|
Experimenting diff --git a/tests/test_api_urls.py b/tests/test_api_urls.py
index cb0c9c9..4d6f887 100644
--- a/tests/test_api_urls.py
+++ b/tests/test_api_urls.py
@@ -27,7 +27,7 @@ class TestAPIURLs(unittest.TestCase):
def setUp(self):
# Switch to False here because we don't want to send the mocked
# Fixture data. Which is OK because these don't touch GitHub API data.
- webcompat.app.config['TESTING'] = False
+ webcompat.app.config['TESTING'] = True
self.app = webcompat.app.test_client()
def tearDown(self):Then I can see two options:
Summary of the failure:
|
|
Let's see, the simplest seems to be: ERROR: API with wrong parameter returns JSON 404 With which triggers The issue with the test is that it triggers an HTML response instead of a JSON response. HTTP/1.0 404 NOT FOUND
Content-Length: 5784
Content-Type: text/html; charset=utf-8
Date: Mon, 15 Feb 2016 05:27:25 GMT
Server: Werkzeug/0.10.4 Python/2.7.10hmmm I have the feeling that the mockable_response is somewhat screwing up the test. ping @miketaylr |
|
ok understood it's really the The fixture is trying to send what "webcompat.com" would reply to such a request. I have the feeling it is not the fixture we want. The fixtures should be here to avoid the calls to GitHub. So basically, we need to mock |
I think you're right. I don't recall 100% why I didn't take this route initially -- I think it had to do something with the fact that I wasn't sure how to get to the right fixture data from the method call without adding 20 if/else statements based on args into the method. But I bet you can think of a better way. This would be a very cool contribution. 💐 (and maybe we just define a decorator or two that handles the ugly argument -> fixture handling and toss that in helpers.py and we're done). |
|
Yes it's completely logical what you did and a lot easier. I was reading about MagicMock yesterday and I'll have to try to really understand. I was trying to understand if the side effects feature is exactly what you are mentioning about the specific cases in front of the generic mocking object. To explore. Still I want to sit ⑁ with you in a café ☕️ and go on pair 👬 reading the code. Ah the future of transportation… 🚀 |
|
https://blog.fugue.co/2016-02-11-python-mocking-101.html looks interesting, will take a look at some point soon. (brb, finding a rocketship) |
|
That would be a reason to move to 3.5.1 Some ideas for prototyping: in We need variability on 3 parameters for the requests:
Depending on that the responses will be different.
https://docs.python.org/3/library/unittest.mock.html#auto-speccing Basically it seems it will copy the interface of the class you are mocking. So I guess in our case either Github Flask or requests modules.
|
|
Another useful article http://engineroom.trackmaven.com/blog/real-life-mocking/ |
|
In the test file, we can also do things like from mock import patch, Mock
@patch.dict(webcompat.app.config, {'TESTING': 'True'})
def test_api_issues_search(self):
'''API issue search with bad keywords returns JSON 404.'''
rv = self.app.get('/api/issues/search/foobar', environ_base=headers)
self.assertEqual(rv.status_code, 404)
self.assertEqual(rv.content_type, 'application/json')And here things with fixtures examples: |
|
Ah, this is very cool. |
|
Status update: we want to do this, but need to be able to mock comms with GitHub first (see also #712). |
|
Closing through the work of @brizental on #1618. Congrats! |
We could write some tests around our API endpoints in a similar style to the "URL" unit tests that we currently have, to be run with the
nosetestscommand. When we have Travis running, we'll have it run both functional Selenium tests as well as our nosetests.Logged out state will be easiest, perhaps a good first step.
@karlcow would you like to help out with this? I bet you could sniff out more than a few bugs.
The text was updated successfully, but these errors were encountered: