-
Notifications
You must be signed in to change notification settings - Fork 2
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
Investigate how responses are handled in testing #72
Comments
Some relevant docs: https://www.django-rest-framework.org/api-guide/testing/#rendering-responses |
When don't we use serializers? |
At least one endpoint: |
I don't think we should use serializers simply because we're facing the problem outlined in this issue (without further understanding of the problem), but just to be nerdy: a single string is in fact a basic JSON value, and therefore a @AlmightyYakob, are there other places where we lack a serializer? And in the case of the AQL endpoint, what is the magic that allows for constructing a |
Another place we don't use serializers is in the table Initially, I was thinking it was best to just return the cursor directly, since it works in Django, and it's the most direct path. The main reason for me opening this issue is that since it works in the general django response, I'd like the same response to exist in testing. We could use a serializer in this response, and maybe we should, but if it's just an issue with testing, I'd like to try to solve it there, rather than change our endpoint behavior to accommodate testing. From the docs I linked, it looks like there may be a valid approach there. However, I wouldn't be opposed to using a serializer in that endpoint directly either, so long as it doesn't come with serious disadvantages (which I doubt it will). |
It appears that in a testing context (when using
api_client
orauthenticated_api_client
), data is directly returned from an api endpoint, without serialization. For example, if you directly return an arangodb cursor from an endpoint, inspectingr.data
shows that the type isCursor
. This is in contrast to what we expect from the endpoint, which is serialized JSON. In my example, we can still callr.json()
and it works as expected, but IMO this is still a slight issue, as it represents a difference in our test cases vs reality.This doesn't usually crop up due to our use serializers in most places, but for the rare cases where we don't use serializers, this could cause issues. If nothing else we should be aware of this behavior, but we should also see what we can do to mitigate this.
The text was updated successfully, but these errors were encountered: