Skip to content
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

Provide methods to unambiguously send form data with MockMvc #32757

Closed
wilkinsona opened this issue May 3, 2024 · 0 comments
Closed

Provide methods to unambiguously send form data with MockMvc #32757

wilkinsona opened this issue May 3, 2024 · 0 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@wilkinsona
Copy link
Member

A recent Spring REST Docs issue has reminded me of the ambiguity of using the param method when building a mock request. You cannot tell if the parameter was intended to come from the request's query string or its body which causes REST Docs some problems as it has to guess. Beyond REST Docs, even when setting the content type to indicate that parameters (probably) come from the body, a test like this will fail:

@Test
void formUrlEncodedRequestBuiltWithParam() throws Exception {
	MockHttpServletRequest mockRequest = MockMvcRequestBuilders.patch("/foo")
			.contentType(MediaType.APPLICATION_FORM_URLENCODED).param("a", "alpha")
			.param("b", "bravo").buildRequest(new MockServletContext());
	assertThat(mockRequest.getContentLength()).isGreaterThan(0);
	assertThat(mockRequest.getContentAsString()).isNotEmpty();
}

I discussed this many years ago with @rstoyanchev where he suggested that some new methods specifically for adding form parameters could be introduced. I would welcome such an addition, ideally alongside the deprecation of the param method, as it would allow test code to unambiguously describe the request. This would benefit REST Docs and would also, I believe, allow MockMvc to automatically populate the request's body from the form parameters which, as shown by the test above, it does not do today.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label May 3, 2024
@jhoeller jhoeller added the in: web Issues in web modules (web, webmvc, webflux, websocket) label May 3, 2024
@snicoll snicoll added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels May 8, 2024
@snicoll snicoll self-assigned this May 8, 2024
@snicoll snicoll added this to the 6.1.x milestone May 8, 2024
@snicoll snicoll modified the milestones: 6.1.x, 6.1.7 May 8, 2024
@snicoll snicoll closed this as completed in 6250b64 May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants