spring-projects / spring-framework

Spring Framework
https://spring.io/projects/spring-framework
Apache License 2.0
55.63k stars 37.76k forks source link

Introduce an alternative to WebTestClient based on RestClient #31275

Open EvaristeGalois11 opened 9 months ago

EvaristeGalois11 commented 9 months ago

Hi, I searched the other issues discussing the introduction of RestClient but i couldn't find anything regarding this topic. I apologize if it's been already discussed somewhere.

Currently the only way to call a controller in a RANDOM_PORT environment is through TestRestTemplate (which is a spring boot addition) or with a RestClient instance built for the task. Both of this approaches aren't very nice, given that one must extract from the response object all the parts and then manually asserting on them. WebClientTest on the other hand has a really nice api with the assertions baked in, but it needs all the reactive stuff to be brought in.

A third party alternative is REST Assured which works quite well and has a very nice api, but it would be better i think to not have to rely on some external libraries for this type of thing.

Could it be possible to add a very similar api to WebTestClient (RestTestClient?) but without the reactive side of it?

bclozel commented 9 months ago

RestClient is using the same underlying infrastructure as RestTemplate. You can use the same testing infrastructure as a result.

Would https://github.com/spring-projects/spring-boot/issues/37033 solve the problem for you?

EvaristeGalois11 commented 9 months ago

But correct me if I'm wrong @bclozel, the problem is that the testing infrastructure for RestTemplate is very lacking because it was put in maintenance mode a long time ago.

This is how I'd call a controller with TestRestTemplate:

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class SomeTestIT {
  @Autowired private TestRestTemplate rest;

  @Test
  void someTest() {
    var response = rest.getForEntity("/something", Something.class);
    assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK);
    assertThat(response.getBody()).usingRecursiveComparison().isEqualTo(expectedObject);
  }
}

There is basically nothing that helps testing the http call itself, all the assertions are manual.

This is instead how it's done with WebTestClient:

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class SomeTestIT {
  @Autowired private WebTestClient webTestClient;

  @Test
  void someTest() {
    webTestClient
        .get()
        .uri("/something")
        .exchange()
        .expectStatus()
        .isOk()
        .expectBody(Something.class)
        .isEqualTo(expectedObject);
  }
}

It's just a much more polished and pleasant api to work with. Also it could easily be integrated with spring rest docs to generate some nice documentation, which couldn't be done with TestRestTemplate because it isn't supported :cry: .

Regarding https://github.com/spring-projects/spring-boot/issues/37033 I don't think it is enough because they are discussing about a RestClient.Builder being provided by spring boot, which at most can permit to construct a bare bone RestClient which has the same problems of TestRestTemplate.

rstoyanchev commented 7 months ago

@EvaristeGalois11 you probably are aware, but just in case, you can use WebTestClient against MockMvc as the server. There are examples of that throughout the reference docs. Also, as a test client, WebTestClient has a synchronous API, and you don't need to be exposed to anything reactive unless you want to (e.g. if streaming events).

ciscoo commented 3 months ago

you don't need to be exposed to anything reactive unless you want to (e.g. if streaming events).

You would still need spring-webflux on the classpath which is kind of (not really but still) exposing reactive bits. Without it the default (DefaultWebTestClientBuilder) throws an error.

wind57 commented 3 months ago

@ciscoo

<scope>test</scope> ?

MrBuddyCasino commented 1 month ago

I was just looking for a test equivalent of RestClient and stumbled over this issue, because I wanted to avoid adding the webflux dependency (reactive API is the plague and thankfully killed by virtual threads).

Using WebTestClient in the meantime is ok I guess, since the dependency scope can be limited to test, but it feels unnecessary. Would appreciate it if this would be put on the roadmap.