Introduce overloaded MockPart constructor that accepts the Content-Type

[HyeongMokJeong]

This PR introduces a constructor to MockPart, enabling the configuration of Content-Type.

When testing controllers that expect a specific format, such as JSON, as @RequestPart, this resolves the issue of encountering a 415 status code problem.

[pivotal-cla]

@HyeongMokJeong Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-cla]

@HyeongMokJeong Thank you for signing the Contributor License Agreement!

[sbrannen]

Hi @HyeongMokJeong,

Congratulations on submitting your first PR for the Spring Framework! 👍

Out of curiosity, why do you think the content type warrants a dedicated constructor for MockPart?

Have you considered setting the content type after instantiating the MockPart as follows?

MockPart mockPart = new MockPart("myPart", """
		{"foo": "bar"}
		""".getBytes());

mockPart.getHeaders().setContentType(MediaType.APPLICATION_JSON);

[HyeongMokJeong]

Hi @sbrannen

Thank you for revising the title and providing feedback.

I may not have advanced skills, but I think it would be convenient if HttpHeaders could be configured more flexibly.
I understand the benefits of having constrained code, but I'm curious about how it would be in this case(MockPart).
In that context, Can I hear your opinion on initializing HttpHeaders through the constructor?

Like this

    public MockPart(String name, @Nullable String filename, @Nullable byte[] content, HttpHeaders headers) {
        Assert.hasLength(name, "'name' must not be empty");
        this.name = name;
        this.filename = filename;
        this.content = (content != null ? content : new byte[0]);
        this.headers = headers;
    }

[sbrannen]

In that context, Can I hear your opinion on initializing HttpHeaders through the constructor?

After taking a closer look at jakarta.servlet.http.Part, I think we should in fact introduce an overloaded constructor that allows one to set the content type at the outset.

The rationale is that Part provides first-class support for getting the content type, name, and submitted file name; whereas, MockPart only allows the latter two to be set via a constructor.

So first-class support for the content type is the only attribute missing in terms of symmetry.

As an alternative, we could consider introducing a setContentType(...) method like we have in MockHttpServletRequest, but I think introducing an overloaded constructor is a better option since one always has access to the HttpHeaders via getHeaders() if one wishes to set a specific header after MockPart has been instantiated.

In light of that, let's keep the API minimal and go with your original proposal in this PR.

[sbrannen]

This has been merged into main in a596c0e and revised in db48813.

Thanks