Add an example showing how to use AutoConfigureRestDocs with WebTestClient

[jnizet]

@AutoConfigureRestDocs used with WebTestClient causes the following NullPointerException:

java.lang.NullPointerException
	at java.util.HashMap.putMapEntries(HashMap.java:501)
	at java.util.HashMap.<init>(HashMap.java:490)
	at org.springframework.restdocs.webtestclient.WebTestClientRestDocumentation.retrieveConfiguration(WebTestClientRestDocumentation.java:143)
	at org.springframework.restdocs.webtestclient.WebTestClientRestDocumentation.lambda$document$0(WebTestClientRestDocumentation.java:80)
	at org.springframework.test.web.reactive.server.DefaultWebTestClient$DefaultBodyContentSpec.lambda$consumeWith$3(DefaultWebTestClient.java:540)
	at org.springframework.test.web.reactive.server.ExchangeResult.assertWithDiagnostics(ExchangeResult.java:197)
	at org.springframework.test.web.reactive.server.DefaultWebTestClient$DefaultBodyContentSpec.consumeWith(DefaultWebTestClient.java:540)
	at com.example.demo.web.UserControllerWithAutoconfigureDocTest.shouldGetUser(UserControllerWithAutoconfigureDocTest.java:31)

Here's a complete minimal test case reproducing the problem: https://github.com/jnizet/webtestclientrestdocsissue

See the failing test, with the complete stack trace, in https://github.com/jnizet/webtestclientrestdocsissue/blob/master/src/test/java/com/example/demo/web/UserControllerWithAutoconfigureDocTest.java

The same test not using REST Docs passes: https://github.com/jnizet/webtestclientrestdocsissue/blob/master/src/test/java/com/example/demo/web/UserControllerTest.java

And the same test using REST docs but configuring it manually also passes: https://github.com/jnizet/webtestclientrestdocsissue/blob/master/src/test/java/com/example/demo/web/UserControllerWithApplicationContextDocTest.java

[nosan]

hi @jnizet, UserControllerWithAutoconfigureDocTest does not work, because you have used @SpringBootTest instead of @WebFluxTest. This sample works perfectly.

@WebFluxTest
@AutoConfigureRestDocs
public class UserControllerWithAutoconfigureDocTest {

	@Autowired
	private WebTestClient webTestClient;

	@Test
	void shouldGetUser() {
		webTestClient.get()
				.uri("/users/{id}", 42L)
				.exchange()
				.expectStatus().isOk()
				.expectBody()
				.consumeWith(document("users/get1"));

	}
}

There is some background why it did not work with @SpringBootTest.
WebTestClientAutoConfiguration is not added as a part of your context (as it can be imported in case of @WebFluxTest), hence WebTestClient was added by WebTestClientContextCustomizer (in case if @SpringBootTest has been used) which does not apply any WebTestClientBuilderCustomizers.

One of the WebTestClientBuilderCustomizers is RestDocsWebTestClientBuilderCustomizer which adds a filter WebTestClientRestDocumentationConfigurer during WebTestClient customization.

[jnizet]

Thanks a lot @nosan, and sorry for the noise.

I guess this issue can be closed then. Or maybe it should be kept open only to add an example in the user guide showing how to use AutoConfigureRestDocs in conjunction with WebFluxTest. Currently, there is an example for MockMVC and an example for RestAssured, but none for WebTestClient.

[wilkinsona]

Thanks for the detailed report, @jnizet, and for helping out with the explanation, @nosan. I think an addition to the documentation is needed here. It should have happened as part of #15220 but apparently I missed it.

[nosan]

@wilkinsona
I can create a PR, to add an extra check on NullPointerException in WebTestClientRestDocumentation.

private static Map<String, Object> retrieveConfiguration(ExchangeResult result) {
		Map<String, Object> configuration = new HashMap<>(/*null pointer, configuration is not present */
				WebTestClientRestDocumentationConfigurer
						.retrieveConfiguration(result.getRequestHeaders()));
		configuration.put(RestDocumentationGenerator.ATTRIBUTE_NAME_URL_TEMPLATE,
				result.getUriTemplate());
		return configuration;
	}

What do you think ?

[wilkinsona]

Thanks for the offer. The problem isn't specific to WebTestClient and REST Docs' MockMvc and REST Assured integration can fail in a similar way. I think it's right that it fails and I don't think that just adding a null check would be an improvement. It may, however, be an improvement to check for the configuration being null and, if it is, throwing something like an IllegalStateException that guides the user towards the integration with whatever testing client is in use being incorrectly configured.