-
Notifications
You must be signed in to change notification settings - Fork 300
Add tests using default DRF classes #490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add tests using default DRF classes #490
Conversation
@sliverc Here's the initial progress. |
1e71502
to
b42b20b
Compare
Thanks @Alig1493 This looks like a good start. The test you are covering here is based on rendering. I think it will also be important to test parsing with DRF serializers resp. the full request/response cycle. This could be something like |
Alright I'll go take a look. |
@sliverc I had some issues regarding testing the response of the default drf serializer urls: I took the approach of making new serializers for the Blog model using the default serializer and adding it as a viewset in urls. I didn't make new files for these and added the code to the existing code base. Should I push into the PR for you to check? Thanks. |
@Alig1493 yep you will add custom DRF viewsets for this to work. I am fine when they are in the same file as it just a variant of the other tests. So 👍 to push |
@sliverc pushed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great. It's shaping up nicely. See my comments. Also it would still be great to have a test which either does a post or patch on the DRF view (I guess the same view could be used).
example/serializers.py
Outdated
@@ -50,6 +58,25 @@ class Meta: | |||
meta_fields = ('copyright',) | |||
|
|||
|
|||
# DRF default serializer to test default DRF functionalities | |||
class BlogDRFSerializer(serializers.ModelSerializer): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't this be derived from drf_serilazers.ModelSerializer as well? Also best move the comment into the class a block comment.
@@ -73,3 +76,24 @@ def test_render_format_keys(settings): | |||
|
|||
result = json.loads(rendered.decode()) | |||
assert result['data']['attributes']['json-field'] == {'json-key': 'JsonValue'} | |||
|
|||
|
|||
class TestDRFBlogViewSet(TestBlogViewSet): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as all other tests are written in pytest in this module I would write these tests the same way. This way we do not have a dependency on TestBlogViewSet (which basically only creates an entry during setup phase anyway).
'meta': {'apiDocs': '/docs/api/blogs'} | ||
} | ||
got = resp.json() | ||
print(got) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
left over print statement? I guess should be removed.
@@ -0,0 +1,99 @@ | |||
import json | |||
|
|||
from django.urls import reverse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Imports are in invalid order according to isort.
See https://travis-ci.org/django-json-api/django-rest-framework-json-api/jobs/440153239#L936
@pytest.mark.django_db | ||
def test_get_object_gives_correct_blog(client, blog, entry): | ||
|
||
url = reverse('drf-entry-blog', kwargs={'entry_pk': entry.id}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sliverc I have used reverse here.
settings.JSON_API_FORMAT_KEYS = 'dasherize' | ||
rendered = render_dummy_test_serialized_view(DummyTestViewSet) | ||
|
||
result = json.loads(rendered.decode()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sliverc as for json here's the usage
@sliverc apologies for taking so long to get back to you I became occupied with something else for some time. One thing that I was wondering is that if it would be possible for you to guide me as to how to make put/patch requests using modelviewsets. I've mostly used generic class based views, although that's no excuse. My initial attempt in trying to patch the |
@sliverc Update: I've figured out how to patch using routers and model viewsets. Hopefully you'll be able to review it soon. My remaining question is that when posting data should I be only creating a Blog object, or will I have to link the blog object to the entry object to which it's related. |
315ab6c
to
ebc5e4f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Create test looks good. Let's leave it as is for now we might add relationships creation later one when there is a need.
Some small comments remain. Would also be great if you could add yourself to AUTHORS.
example/tests/conftest.py
Outdated
|
||
|
||
@pytest.fixture | ||
def blog(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually not needed as this is automatically done with pytest-factoryboy where this factory is registered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that's my bad on not seeing the registered factories.
blog = Blog.objects.filter(name=name) | ||
|
||
# check if blog exists in database | ||
assert blog.exists() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this asserts is not needed as the next asserts checks already whether it exists by counting it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.
assert blog.count() == 1 | ||
|
||
# get created blog from database | ||
blog = blog[0] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
blog.first()
might be more elegant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OF COURSE. Completely missed that train of thought.
@sliverc I have made changes as per your review. Please have a look. |
@sliverc WIth your permission I've also included my name to authors. Put that in a seperate commit if that's okay. |
Looks good. It needs to be rebased to current master and CI isort issue https://travis-ci.org/django-json-api/django-rest-framework-json-api/jobs/441354640 fixed and the in should be ready. |
@sliverc I can do the rebase, but I'll need more insight on the isort issue. It's been there since my first push! |
Isort is a package that sorts imports alphabetically. So I just have to fix my order of imports? |
136f7c1
to
b7b6606
Compare
@sliverc Travis CI seems to be stuck. Could you please give more insight on this issue? :s |
@Alig1493 Usually pushing again to the branch helps. I guess you can rebase to master and resolve the conflicts and push again. |
…in request response cycle
b7b6606
to
5780a68
Compare
@sliverc it seems all's well for now. |
Great. Thanks for your contribution. Merged. In case you want to extend your tests to address #298 that would be great. Feel free. |
I'd love to extend my help if possible. I'll take a look and ask if there's any questions. |
Fixes #283
Description of the Change
Checklist
CHANGELOG.md
AUTHORS