Unexpected different behavior between exposed API and Unit Test APIClient request

[jlandercy]

My use case is the following: I have Items that have Properties. There is a Many 2 Many relationship between them. I want to be able to create Items with Properties that are created on the fly. I mean if property exists it is fetched, if it does not it is created. I can do so using the following pattern:

# models.py

class Property(models.Model):
    name = models.CharField(max_length=64, unique=True)


class Item(models.Model):
    name = models.CharField(max_length=64, unique=True)
    properties = models.ManyToManyField(Property, through="ItemProperty")


class ItemProperty(models.Model):
    property = models.ForeignKey(Property, on_delete=models.CASCADE)
    item = models.ForeignKey(Item, on_delete=models.CASCADE)

class PropertySerializer(serializers.Serializer):
    name = serializers.CharField()

# serializer.py

class ItemSerializer(serializers.ModelSerializer):

    properties = PropertySerializer(many=True, required=False)

    class Meta:
        model = models.Item
        fields = "__all__"

    def create(self, validated_data):
        data = copy.deepcopy(validated_data)
        properties = data.pop("properties", [])
        item = models.Item.objects.create(**data)
        for property in properties:
            current_property, _ = models.Property.objects.get_or_create(**property)
            item.properties.add(current_property)
        return item

# views.py

class PropertyViewSet(viewsets.ModelViewSet):
    queryset = models.Property.objects.all()
    serializer_class = serializers.PropertySerializer
    permissions_classes = [permissions.IsAuthenticated]


class ItemViewSet(viewsets.ModelViewSet):
    queryset = models.Item.objects.all()
    serializer_class = serializers.ItemSerializer
    permissions_classes = [permissions.IsAuthenticated]

router.register('property', PropertyViewSet, 'property')
router.register('item', ItemViewSet, 'item')

With this setup, when I perform a POST request with the following payload on the API directly (using Swagger):

{
        "name": "test",
        "properties": [{"name": "test"}, {"name": "dummy"}]
}

I get a 201 with the following body:

{
  "id": 3,
  "properties": [
    {
      "name": "test"
    },
    {
      "name": "dummy"
    }
  ],
  "name": "test"
}

Which is the expected result (property are created on the fly). Now if I want to automatize this check using Unit Test, I'll do something like this:

class TestAPIItemsAndProperties(APITestCase):

    fixtures = ["core/fixtures/users.yaml"]

    payload = {
        "name": "test",
        "properties": [{"name": "test"}, {"name": "dummy"}],
    }

    def setUp(self):
        self.user = models.CustomUser.objects.get(username="jlandercy")
        self.client = APIClient()
        self.client.force_authenticate(user=self.user)

    def test_complete_payload_is_sent(self):
        response = self.client.post("/api/core/item/", data=self.payload)
        print(response)
        print(response.json())

And then I get a 201 where properties are totally ignored (seems like they are popped):

{'id': 1, 'properties': [], 'name': 'test'}

I wonder if I am doing something wrong in automatizing test or if it is potentially a bug.

[jlandercy]

May I ask why not being able to reproduce the API behaviour in Unit Test is just a discussion and not an issue ?

[tomchristie]

@jlandercy What is your expectation here?

[jlandercy]

@tomchristie My Goal is to be able to create Unit Test that actually does reproduce the real behaviour of logic I have written. I have showed by an example that it is not the case in some simple scenario. I report it because I think it is an important point to share. And indeed I would like to find out a solution.

As you can see the issue has directly been converted into a discussion. I don't understand why but that is not the main concern.

Can we focus on the original issue? Or is it something the community doesn't want to address? If so why?

[browniebroke]

This is generally the process in this project: start with a discussion and let maintainers convert to an issue if applicable. Granted, it's not well documented at the moment (it was removed in https://github.com/encode/django-rest-framework/pull/9660/files#diff-e47c48e8f0317724062520e87f0d688e0b80ab197d4ac083445782243caae14fL33 and not restored), but this is it.

The rationale is that DRF user base is so big that most changes (even minor fixes) can be considered breaking changes and should be avoided unless absolutely necessary. Another way of saying that is that all currently exhibited behaviour are most likely considered "expected" by a vast majority of our users and are often best addressed by adjusting the user understanding. Leaving a discussion open is more visible and helpful to others facing the same problem than a closed issue.

I'm not saying your issue is definitely not a bug, but it's more of a case of "not a bug until proven to be".