Explain how Vert.x Web Client can be used for integration tests

[sberyozkin]

Description

Vert.x Web Client is proving to be superior to RestAssured in several areas.
For example, I've spent a lot of time trying to chase why RestAssured fails to resolve a public Auth0 tenant address, and I still don't know - because I switched to Vert.x Web Client - sometimes it takes a bit of time, but it works most of the time.
The other area is where we need to test various URI variations as confirmed during the recent work by Michal Vavrik.

Implementation ideas

RestAssured is still a valuable testing tool, so the proposal is to add a Vert.x Web Client section to the REST Client guide explaining which dependency to add, how to create and close it, and how to make typical GET and POST calls

[geoand]

If this is just about documenting Vert.x WebClient as an alternative to RestAssured, I think it's fine.

If however the proposal is to make Vert.x WebClient an alternative in the generated projects, then I'm -1, because in a lot of cases it's harder to use then RestAssured and mainly because it will increase confusion about the necessity of using reactive over imperative APIs

[geoand]

cc @cescoffier

[cescoffier]

That's only for our internal tests.
REST Assured does magic that hides some behavior (like the path issue). So we were unable to reproduce the problem with it.

There are feature that you cannot have in RESTAssured (pipelining, TLS with exotic certs...). They need to be covered.

So, I think what @sberyozkin has in mind is a short ADR explaining why internally (when testing extensions) we should use the WebClient instead of RESTAssured when we want to test HTTP behavior (if your goal is to trigger some processing in your app, keep RESTAssured).

[geoand]

Ah, that's something different indeed!

[sberyozkin]

@geoand @cescoffier, thanks for the feedback.

My only proposal is to add a short section to the REST client testing guide, explaining how users can use WebClient, if they need to. I have 2 cases in mind:

• if someone needs to write tests with request paths containing //, then RestAssured does not work, it normalizes the paths before the requests are made
• if the test needs DNS resolution for a public URL, RestAssured just hangs, WebClient works

I can propose a simple PR a bit later

[sberyozkin]

I suppose recommend in the issue title reads a bit misleading, let me rename