A good way to compare the expected queryset with the results of the response

[Antoliny0919]

I have a question when comparing the response(.data) and queryset object.

class Dog(models.Model):
    ...
    hungry = models.BooleanField(default=False)
    hurt = models.BooleanField(default=False)

As an example, let's say there is a class called Dog and there is logic in View to get a list of hungry dogs.
I'm going to make a test about the logic of get a list of hungry dogs.

class ...
    def test_dog_hungry_list(self):
        response = client.get("/api/dog/hungry/")
        expected_response = Dog.objects.filter(hungry=True)
        self.assertEqual(response.data, expected_response)

The two values that I want to compare with assertEqual, response and expected_response, are of different types.

• response --> Response
• expected_response --> Queryset

In the case of response.data, Serializer is applied, so when it's in dict form, I want to compare it with Queryset type expected_response.
There are two ways I came up with it.

1. Apply serializer to Queryset for comparison. --> (Serializer(expected_response, many=True))
2. Compare the primary key values.

number 2 example.

expected_response = Dog.objects.filter(hungry=True).values("id")
self.assertEqual(
[data["id"] for data in response.data],
[data["id"] for data in expected_response]
)

But I'm not sure if the two methods are good in comparison.
In the end, there are two questions.

1. Is it right to proceed with the above test when I write the logic to get hungry dogs as an example?
2. What are some good ways to compare the value of being serializer with the value of Queryset?
3. Is there a repository where I can find examples of test codes written well?

[TGoddessana]

I think you can check cookiecutter-django repository.

https://github.com/cookiecutter/cookiecutter-django/blob/master/%7B%7Bcookiecutter.project_slug%7D%7D/%7B%7Bcookiecutter.project_slug%7D%7D/users/tests/test_drf_views.py

Personally, i prefer the raw data(python dict, list …) in tests, not using serializer to make dict in tests.

[Antoliny0919]

Thank you for your reply @TGoddessana
Through the source code of the storage your recommended(cookiecutter-django), I was able to know the test method through the APIRequestFactory class provided by DRF.
(It was interested!)

But I'm not sure yet. If the expected data size is a little bit large, then I have to enter too much to make a static comparison. What should I do in this case?

[browniebroke]

Make your test more focused, reducing its scope:

• don't create 100s of objects in your test setup
• try to ask yourself: what is this test testing? What do I really care about? If the answer contains one or more "and", it sometimes mean that you should split into multiple tests
• if the response payload is actually large, perhaps your endpoint is returning too much at once and it may be an indication that it should be broken down

Personally, I like to create a single entry to test the retrieve part of my viewset, and check the full payload, status code, etc... But in case of list/filter endpoints, I would only check the ID / name attribute to make sure the ones I expect to see are present, not the full payload.

With your example, create a hungry dog, create a not hungry dog, call the endpoint with hungry=1, check that only the hungry one is returned, call with hungry=0 and check that only the not hungry one is returned.

[Antoliny0919]

That's a good thing to say 💪
For List/Filter endpoints, I do not need to check all fields.
I only need to check the PrimaryKeyField, Id.
I also sympathized with that part and have used the code as below.

expected_response = Dog.objects.filter(hungry=True).values("id")
self.assertEqual(
[data["id"] for data in response.data],
[data["id"] for data in expected_response]
)

I was a little uncomfortable used the list comprehension to get only the id value from this part.
(wondered if it was right to conduct the test through these conversions...)
However, when I saw your answer, I felt there was no problem with the process of going through this conversion because it was a process to get "Id" values.
It was very helpful, thank you @browniebroke.