Add support to WebTestClient for consuming the ExchangeResult [SPR-15587]

[spring-projects-issues]

Andy Wilkinson opened SPR-15587 and commented

WebTestClient, via BodyContentSpec, currently allows the body to be consumed with a Consumer or the result to be returned. I'd like to be able to consume the result too. Perhaps something like the following on BodyContentSpec:

BodyContentSpec consumeAsResultWith(EntityExchangeResult<byte[]> consumer);

I do wonder if this is, perhaps, pulling BodyContentSpec as bit too far away from dealing with the body's content. As an alternative, could the method be added to ResponseSpec? It would decode the UndecodedExchangeResult and then pass the resulting EntityExchangeResult to the Consumer? If it did so, I'm not sure what the method would return to allow the chaining of further method calls.

---

Affects: 5.0 RC1

Referenced from: commits 346d5d2

[spring-projects-issues]

Rossen Stoyanchev commented

I've made changes to replace the Consumer<T> methods with Consumer<EntityExchangeResult<T>>.

Note at the ResponseSpec stage of the workflow we only have status and headers. The body is not consumed. You have to go one step further into the workflow so we know how to decode the body. There are several expectBodyXxx options to branch off to and they're all mutually exclusive in the workflow, i.e. there is no returning back to ResponseSpec:

// Decode to single entity
.expectBody(Person.class).consumeWith(result -> ...);

// Decode to list of entities
.expectBodyList(Person.class).consumeWith(result -> ...);

// Raw content (jsonPath, json, empty body, etc)
.expectBody().consumeWith(result -> ...);

At ResponseSpec we could of course read the body to byte[] but then it wouldn't make sense to branch off into the first two of the above so that messes with the workflow. We could easily add Consumer<FluxExchangeResult<T>> in ResponseSpec if you think that'd be useful. We already have a returnResult() for it.

Note also that there is always a way to get the raw content regardless of how the body is decoded. For example suppose you decoded to EntityExchangeResult<Person>, you could then use result.getResponseBody() to get the Person but also ExchangeResult#getResponseBodyContent() to get the raw content that was read. This is possible because the raw content is recorded as it is being consumed. The result.getResponseBody() method by the way works even with FluxExchangeResult<T> where it will cause the Flux<T> to be consumed (and its elements ignored) but the raw content is recorded still.

Of course with FluxEntityResult typically you want the application to consume the elements in the Flux (rather than having them ignored) but regardless, the simple rule of thumb is that as long as you have an instance of ExchangeResult, you can get the raw content from it with result.getResponseBodyContent(). So for the purposes of REST Docs, you can let the application decode the body however it wants and call one of the consumeWith methods where you'll have access to the raw content.

One last thought. An application could even consume the FluxExchangeResult with Reactor's StepVerifier which allows it to test a streaming scenario, read the first N elements, then cancel the stream. After that it can pass the FluxExchangeResult to REST Docs and it can access the raw content consumed.

[spring-projects-issues]

Rossen Stoyanchev commented

Not to forget the request body content... if you have an ExchangeResult instance you can always get both the raw request and response body content regardless of how input was provided and output processed (via higher-level entities).

[spring-projects-issues]

Andy Wilkinson commented

Thanks, Rossen. I haven't had a chance to try things out with a FluxExchangeResult, but things are working very nicely with an EntityExchangeResult now.

[spring-projects-issues]

Rossen Stoyanchev commented

Good to hear.