Conversation
|
As mentioned in the online comment, the tests never actually test the task result - just the fact that the task exists. You can look into https://docs.celeryproject.org/projects/django-celery/en/2.4/cookbook/unit-testing.html#using-a-custom-test-runner-to-test-with-celery on how to easily test task results. An alternative approach is described in https://medium.com/@erayerdin/how-to-test-celery-in-django-927438757daf |
| def test_add_podcast_new(self): | ||
| """Test add podcast API for new podcast""" | ||
| podcast_url = 'http://example.com/new-podcast.xml' | ||
| add_url = reverse('api-add-podcast') | ||
| body = {'url': podcast_url} | ||
| add_resp = self.client.post(add_url, body, content_type='application/json') | ||
| self.assertEqual(add_resp.status_code, 202) | ||
| status_url = add_resp.get('Location') | ||
| status_resp = self.client.get(status_url) | ||
| self.assertEqual(status_resp.status_code, 200) | ||
| self.assertEqual(status_resp.json().get('status'), 'pending') |
There was a problem hiding this comment.
If I understand this test correctly, it only tests whether a task has been started - but not its result.
There was a problem hiding this comment.
@stefankoegl
I add tests for the Celery task result below.
Celery testing is particularly tricky. I've tried the two references you provided but could get neither pytest fixture or pytest-django working for Celery. I turn to celery.app.task.Task.apply() to execute the task ad-hoc.
The problem is that the Celery instance is the one from mygpo.celery, the same as the real one, thus accessing the production database. I think this is a potential problem. But I can't find a better solution at the moment.
Any suggestion is appreciated. 😄
There was a problem hiding this comment.
The problem is that the Celery instance is the one from mygpo.celery, the same as the real one, thus accessing the production database.
When running tests, the DATABASE setting is initialized to point to the test database (see https://docs.djangoproject.com/en/dev/topics/testing/overview/#the-test-database). Therefore I don't think its possible to access the prod database through mygpo.celery from within a test. These two should be completely isolated from each other.
There was a problem hiding this comment.
@stefankoegl Does the new PR for testing meet the requirement? If so, I'll move on to documentation and hopefully close the issue. 😄
| self.assertEqual(status_resp.status_code, 200) | ||
| self.assertEqual(status_resp.json().get('status'), 'pending') | ||
| job_id = status_url.split('/')[-1] | ||
| result = update_podcasts.apply(task_id=job_id) |
There was a problem hiding this comment.
Could you add a comment describing what this does exactly? That might not be obvious for somebody reading the code in the future.
| self.assertEqual(status_resp.json().get('status'), 'pending') | ||
| job_id = status_url.split('/')[-1] | ||
| result = update_podcasts.apply(task_id=job_id) | ||
| self.assertTrue(result.ready()) |
There was a problem hiding this comment.
I think we're still not testing the end result. Now the test checks whether the task has completed, but what we actually want to achieve is to have a new podcast. I think that the checks should verify that a podcast with the submitted URL has been created.
See #219 for more info.