Add `WebTestClient` and `TestHttpResponse` to enable more fluent testing of HTTP responses #4740

tomatophobia · 2023-03-10T05:53:15Z

Motivation:

Related issue: Add WebTestClient #4339
In the existing code that tests HTTP responses, there was some redundant code present.
It would be helpful to have a method that enables more fluent testing.

Modifications:

Add TestHttpResponse, which is similar to AggregatedHttpResponse, and includes additional assertion methods.
- One of the assertion methods in TestHttpResponse, assertStatus, allows you to assert the status of the response and returns the TestHttpResponse object, enabling you to test other aspects of the response more fluently.
Add WebTestClient that returns TestHttpResponse by default

Results:

Closes Add WebTestClient #4339
Users can now use multiple assertion methods to test responses more fluently.
The code below contrasts testing a REST API using WebClient versus testing it using WebTestClient.

@RegisterExtension
static ServerExtension server = ...;

@Test
void usingWebClient() {
    final WebClient client = server.webClient();
    AggregatedHttpResponse res;

    res = client.get("/rest/1").aggregate().join();
    assertThat(res.status()).isEqualTo(HttpStatus.OK);
    assertThat(res.headers().contains(...)).isTrue();
    assertThat(res.content().toStringUtf8()).isEqualTo(...);
    assertThat(res.trailers().isEmpty()).isTrue();
}

@Test
void usingWebTestClient() {
    final WebTestClient client = server.webTestClient();

    client.get("/rest/1")
          .assertStatus().isOk()
          .assertHeaders().contains(...)
          .assertContent().stringUtf8IsEqualTo(...)
          .assertTrailers().isEmpty();
}

ikhoon

I didn't have time to fully review this PR. I will see in detail soon.

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/HttpDataAssert.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/TestHttpResponse.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/WebTestClientUtil.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/DefaultWebTestClient.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/AssertThat.java

ikhoon

Sorry for the late review.
The overall direction looks good although we need minor changes and polish Javadoc.

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/WebTestClientUtil.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/TestHttpResponse.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/AssertThat.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/TestHttpResponse.java

ikhoon · 2023-07-12T10:16:18Z

I suggest you apply the WebTestClient for some existing code to see how well the current design covers our existing tests.

As you know, we usually use AssertJ. Maybe in the follow-up PR, we can add armeria-assertj module that our team mostly uses for Armeria testing.

var testClient = AssertjWebTestClient.of(server.webClient());

tomatophobia · 2023-07-12T14:52:40Z

I suggest you apply the WebTestClient for some existing code to see how well the current design covers our existing tests.

As you know, we usually use AssertJ. Maybe in the follow-up PR, we can add armeria-assertj module that our team mostly uses for Armeria testing.
var testClient = AssertjWebTestClient.of(server.webClient());

(I'm sorry, but I couldn't leave a reply due to a bug on GitHub, so I left a comment instead.)

I completely agree with your opinion. I will contribute as a follow-up to this PR. 😄 👍

In fact, initially I wrote the code using AssertJ according to the developer guide, but due to dependency issues, I ended up using the JUnit API.

I have a question at this point. junit5 module of armeria depends on libs.junit5.jupiter.api but it doesn't depend on libs.assertj. Is it strange to add the dependency on libs.assertj to the junit5 module in the current situation? Do you prefer creating a new armeria-assertj module as you mentioned in the comment?

(related #4740 (comment))

1. Remove RESPONSE_STREAMING_REQUEST_OPTIONS static variable. 2. Remove unused factory methods. 3. Replace checkState method with junit5 Assertions API

override requestAutoAbortDelay, requestAutoAbortDelayMillis

…il`.

tomatophobia

The newly added exception test API is as follows.

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/AbortedTestHttpResponse.java

junit5/src/test/java/com/linecorp/armeria/testing/junit5/client/WebTestClientTest.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/AbortedTestHttpResponse.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/DefaultTestHttpResponse.java

ikhoon · 2023-07-27T06:53:54Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/DefaultTestHttpResponse.java

+        if (this == obj) {
+            return true;
+        }
+
+        if (!(obj instanceof TestHttpResponse)) {
+            return false;
+        }
+
+        final TestHttpResponse that = (TestHttpResponse) obj;
+
+        return informationals().equals(that.informationals()) &&
+               headers().equals(that.headers()) &&
+               content().equals(that.content()) &&
+               trailers().equals(that.trailers());


Suggested change

if (this == obj) {

return true;

}

if (!(obj instanceof TestHttpResponse)) {

return false;

}

final TestHttpResponse that = (TestHttpResponse) obj;

return informationals().equals(that.informationals()) &&

headers().equals(that.headers()) &&

content().equals(that.content()) &&

trailers().equals(that.trailers());

if (this == obj) {

return true;

}

if (!(obj instanceof TestHttpResponse)) {

return false;

}

final TestHttpResponse that = (TestHttpResponse) obj;

return delegate.equals(that.unwrap());

Before using delegate.equals(), I first cast obj to TestHttpResponse, and then unwrap() it before using it as an argument. I made this change because when using obj without casting it to TestHttpResponse, the result was always false if the runtime type of obj was TestHttpResponse.

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/DefaultTestHttpResponse.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/HttpHeadersAssert.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/ThrowableAssert.java

ikhoon · 2023-07-27T07:07:33Z

This PR seems ready to review by other maintainers. Let's get some opinions about the current direction. PTAL

codecov · 2023-07-28T08:39:43Z

Codecov Report

Attention: Patch coverage is 30.23810% with 293 lines in your changes are missing coverage. Please review.

Project coverage is 73.82%. Comparing base (b8eb810) to head (b97719a).
Report is 165 commits behind head on main.

❗ Current head b97719a differs from pull request most recent head 36daaa1. Consider uploading reports for the commit 36daaa1 to get more accurate results

Files	Patch %	Lines
...a/testing/junit5/client/TestBlockingWebClient.java	8.64%	73 Missing and 1 partial ⚠️
...lient/TestBlockingWebClientRequestPreparation.java	26.43%	64 Missing ⚠️
...ng/junit5/client/TestBlockingWebClientBuilder.java	0.00%	39 Missing ⚠️
...meria/testing/junit5/client/HttpHeadersAssert.java	26.53%	36 Missing ⚠️
.../armeria/testing/junit5/client/HttpDataAssert.java	30.76%	18 Missing ⚠️
...rmeria/testing/junit5/client/HttpStatusAssert.java	25.00%	18 Missing ⚠️
...armeria/testing/junit5/client/ThrowableAssert.java	69.23%	11 Missing and 1 partial ⚠️
...testing/junit5/client/DefaultTestHttpResponse.java	56.52%	10 Missing ⚠️
...testing/junit5/client/AbortedTestHttpResponse.java	40.00%	9 Missing ⚠️
...ng/junit5/client/DefaultTestBlockingWebClient.java	57.89%	8 Missing ⚠️
... and 2 more

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #4740      +/-   ##
============================================
- Coverage     73.95%   73.82%   -0.14%     
- Complexity    20115    20917     +802     
============================================
  Files          1730     1819      +89     
  Lines         74161    77163    +3002     
  Branches       9465     9794     +329     
============================================
+ Hits          54847    56963    +2116     
- Misses        14837    15569     +732     
- Partials       4477     4631     +154

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

github-actions · 2023-08-31T17:13:34Z

🔍 Build Scan® (commit: `36daaa1`)

Job name	Status	Build Scan®
build-windows-latest-jdk-19	✅	https://ge.armeria.dev/s/mguuioxre2zgy
build-self-hosted-unsafe-jdk-8	✅	https://ge.armeria.dev/s/h4jmymkg7q6si
build-self-hosted-unsafe-jdk-19-snapshot-blockhound	✅	https://ge.armeria.dev/s/j5bh6n7yzivam
build-self-hosted-unsafe-jdk-17-min-java-17-coverage	✅	https://ge.armeria.dev/s/um4ukacts6dgm
build-self-hosted-unsafe-jdk-17-min-java-11	✅	https://ge.armeria.dev/s/hplmc3syttp4w
build-self-hosted-unsafe-jdk-17-leak	✅	https://ge.armeria.dev/s/txyaimwvitlns
build-self-hosted-unsafe-jdk-11	✅	https://ge.armeria.dev/s/iayh3s5hvas2y
build-macos-12-jdk-19	✅	https://ge.armeria.dev/s/3q56up44oadgi

… content)` override.

jrhee17

Wow that's a lot of code 😅 Looks good overall 👍

~~I'm wondering if it's worth just creating an assertj module at this point. What do you think others?~~

Nevermind this comment 😅 Talked with the team and we decided not to move this to a separate module for this iteration

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/WebTestClient.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/HttpStatusAssert.java

...rc/main/java/com/linecorp/armeria/testing/junit5/client/WebTestClientRequestPreparation.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/WebTestClientBuilder.java

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/HttpDataAssert.java

jrhee17

Looks good overall, left some minor comments

jrhee17 · 2023-09-05T02:28:51Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/AbstractResponseAssert.java

+    TestHttpResponse response() {
+        return response;
+    }
+


What do you think of adding a base assertion which accepts a vararg of consumers?

for (val c: consumers) { assertAll(() -> consumer.accept(actual())); }

Thank you for the suggestion. I'm sorry, but I can't understand the intent behind the suggestion. Could you please clarify in which situations this code is being used?

I was thinking of something like the following so that users could fall back in case they can't find an assertion that is sufficient for their use-case.

@SafeVarargs public final TestHttpResponse satisfies(ThrowableConsumer<T>... consumers) { for (ThrowableConsumer<T> consumer: consumers) { assertAll(() -> consumer.accept(actual)); } return response(); }

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/HttpDataAssert.java

jrhee17 · 2023-09-05T02:36:25Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/HttpDataAssert.java

+    /**
+     * Asserts that the {@link String} representation of actual {@link HttpData} contains the given value.
+     */
+    public TestHttpResponse stringContains(Charset charset, String expected) {


Do you mind also formatting the other methods so that the verb comes first? (following how junit, assertj are naming assertions)

Suggested change

public TestHttpResponse stringContains(Charset charset, String expected) {

public TestHttpResponse containsString(Charset charset, String expected) {

Thanks for the suggestion! When I named the stringContains method, my intention was not to convey "the HTTP content contains the parameter string" but rather "when representing HTTP content as a string, it contains the provided string as an argument." If I were to name it more explicitly, it might be something like toStringAndItWillContain. The background behind choosing such names was due to the ability to represent HTTP content in various ways, such as UTF-8, ASCII, and others. Initially, I thought of stringUtf8Contains, and then I came up with stringContains.

As you mentioned, it does seem awkward. How about remove the stringUtf8Contains and stringAsciiContains methods and simply use shorter method namescontains(String) and contains(Charset charset, String expected)?

my intention was not to convey "the HTTP content contains the parameter string" but rather "when representing HTTP content as a string, it contains the provided string as an argument."

I see, ideally I think we would as a StringAssert class then and chain like the following:

assertContent().asString().isEqualTo(...);

I think this can be done separately though - what do you think of focusing on byte equality since HttpData is essentially a byte array?

Users probably still find this useful - i.e.

assertContent().isEqualTo("".getBytes());

…tatus range assertion method.

jrhee17

Sorry it took a while - did another round. I think this PR is almost done, let me know if anything doesn't make sense 🙇

jrhee17 · 2024-03-26T13:20:22Z

...5/src/main/java/com/linecorp/armeria/testing/junit5/client/TestBlockingWebClientBuilder.java

+ * Use the factory methods in {@link TestBlockingWebClient} if you do not have many options to override.
+ * Please refer to {@link ClientBuilder} for how decorators and HTTP headers are configured
+ */
+public final class TestBlockingWebClientBuilder extends AbstractWebClientBuilder {


Question) I'm not sure how useful this class is given that we can always use TestBlockingWebClient#of(WebClient).

What do you think of removing this class for now and adding it later if there is demand for such a fluent builder?

jrhee17 · 2024-03-26T13:24:59Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/TestBlockingWebClient.java

+ * }
+ * }</pre>
+ */
+public interface TestBlockingWebClient extends ClientBuilderParams, Unwrappable {


What do you think of modifying s.t. TestBlockingWebClient extends BlockingWebClient instead?

I think we could achieve this by:

Rename BlockingWebClientRequestPreparation to DefaultBlockingWebClientRequestPreparation and make BlockingWebClientRequestPreparation an interface

Make TestBlockingWebClient extend BlockingWebClient

Make TestHttpResponse extend AggregatedHttpResponse

We should be able to maintain these APIs more easily this way

jrhee17 · 2024-03-26T13:54:56Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/server/ServerExtension.java

@@ -370,6 +371,24 @@ public RestClient restClient(Consumer<WebClientBuilder> webClientCustomizer) {
        return delegate.restClient(webClientCustomizer);
    }

+    /**


Question) Instead of creating new methods, could we just return TestBlockingWebClient from ServerExtension#blockingWebClient directly?

jrhee17 · 2024-03-26T14:16:08Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/AbstractResponseAssert.java

+    TestHttpResponse response() {
+        return response;
+    }
+


I was thinking of something like the following so that users could fall back in case they can't find an assertion that is sufficient for their use-case.

@SafeVarargs public final TestHttpResponse satisfies(ThrowableConsumer<T>... consumers) { for (ThrowableConsumer<T> consumer: consumers) { assertAll(() -> consumer.accept(actual)); } return response(); }

jrhee17 · 2024-03-26T14:27:41Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/HttpDataAssert.java

+    /**
+     * Asserts that the {@link String} representation of actual {@link HttpData} contains the given value.
+     */
+    public TestHttpResponse stringContains(Charset charset, String expected) {


my intention was not to convey "the HTTP content contains the parameter string" but rather "when representing HTTP content as a string, it contains the provided string as an argument."

I see, ideally I think we would as a StringAssert class then and chain like the following:

assertContent().asString().isEqualTo(...);

I think this can be done separately though - what do you think of focusing on byte equality since HttpData is essentially a byte array?

Users probably still find this useful - i.e.

assertContent().isEqualTo("".getBytes());

jrhee17 · 2024-03-26T14:38:01Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/HttpHeadersAssert.java

+     * Asserts that the actual {@link HttpHeaders} contains the given name and {@link String} value.
+     * The {@code name} and the {@code value} cannot be null.
+     */
+    public TestHttpResponse contains(CharSequence name, String value) {


Suggestion: What do you think of

Removing the other contains* variants since they don't seem to be providing much value - the object is string-ified internally anyways

Accepting Object for the general case

Suggested change

public TestHttpResponse contains(CharSequence name, String value) {

public TestHttpResponse contains(CharSequence name, Object value) {

jrhee17 · 2024-03-26T14:42:32Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/AbstractResponseAssert.java

+    private final TestHttpResponse response;
+
+    AbstractResponseAssert(T actual, TestHttpResponse response) {
+        requireNonNull(actual, "actual");


Note: Although I think it may be useful to let users check nullability via assertions, I don't think it's necessary at this stage. I'd like to focus on getting this PR merged first.

jrhee17 · 2024-03-26T14:49:32Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/ThrowableAssert.java

+     * Asserts that the message of the actual {@link Throwable} starts with the given message.
+     * The {@code message} cannot be null.
+     */
+    public ThrowableAssert hasMessageStartingWith(String message) {


What do you think of removing hasMessageStartingWith|hasMessageNotContaining|hasMessageEndingWith assertions?

I imagine adding a StringAssert later on

e.g.

assertCause().message().startsWith()

jrhee17 · 2024-03-26T14:50:38Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/DefaultTestHttpResponse.java

+    }
+
+    @Override
+    public ThrowableAssert assertCause() {


Matching the class name

Suggested change

public ThrowableAssert assertCause() {

public ThrowableAssert assertThrowable() {

jrhee17 · 2024-03-26T14:52:46Z

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/ThrowableAssert.java

+    private final Throwable cause;
+
+    ThrowableAssert(Throwable cause) {
+        requireNonNull(cause, "cause");


Note: I think the nullibility of this class can be relaxed, but I'd rather we not do this in this already large PR

tomatophobia requested review from ikhoon, jrhee17, minwoox and trustin as code owners March 10, 2023 05:53

tomatophobia changed the title ~~Add WebTestClient and TestHttpResponse~~ Add WebTestClient and TestHttpResponse to enable more fluent testing of HTTP responses Mar 10, 2023

minwoox added this to the 1.24.0 milestone Mar 23, 2023

minwoox added the new feature label Mar 23, 2023

ikhoon reviewed Mar 23, 2023

View reviewed changes

ikhoon modified the milestones: 1.24.0, 1.25.0 Jun 2, 2023

tomatophobia force-pushed the add-web-test-client branch from e69f7b7 to 948df0e Compare July 2, 2023 16:50

ikhoon reviewed Jul 12, 2023

View reviewed changes

tomatophobia added 7 commits July 13, 2023 00:15

Introduce WebTestClient, TestHttpResponse

2390deb

Add explicit null check

02c55c2

Addressed review comments.

97407af

1. Remove RESPONSE_STREAMING_REQUEST_OPTIONS static variable. 2. Remove unused factory methods. 3. Replace checkState method with junit5 Assertions API

Rename WebTestClientPreparation -> WebTestClientRequestPreparation

f44d860

override requestAutoAbortDelay, requestAutoAbortDelayMillis

Move WebClientUtil to the internal package. Remove `WebTestClientUt…

84735ca

…il`.

Refactor AssertThat to AbstractResponseAssert

df601b9

Change toHttpResponse() to unwrap().

7401e66

tomatophobia force-pushed the add-web-test-client branch from 0cfeeac to 7401e66 Compare July 12, 2023 15:15

tomatophobia added 2 commits July 13, 2023 00:20

Remove the error-prone assert statement.

2c829df

Add exception assert API

914a3b8

tomatophobia commented Jul 14, 2023

View reviewed changes

junit5/src/main/java/com/linecorp/armeria/testing/junit5/client/AbortedTestHttpResponse.java Outdated Show resolved Hide resolved

junit5/src/test/java/com/linecorp/armeria/testing/junit5/client/WebTestClientTest.java Outdated Show resolved Hide resolved

tomatophobia added 3 commits July 18, 2023 23:16

Fix the lint error.

4c3cb6b

Merge branch 'main' into add-web-test-client

690dc81

Fix the lint error.

5c233da

ikhoon reviewed Jul 27, 2023

View reviewed changes

Fix failing test, add new assertion method test.

1e84d58

Fix lint error.

209e0c1

ikhoon modified the milestones: 1.25.0, 1.26.0 Jul 30, 2023

tomatophobia added 3 commits August 5, 2023 21:13

Merge branch 'main' into add-web-test-client

12608ae

Merge branch 'main' into add-web-test-client

4e94b87

Merge branch 'main' into add-web-test-client

98c134b

Newly added `HttpMessageSetters content(Publisher<? extends HttpData>…

32325ba

… content)` override.

jrhee17 reviewed Sep 4, 2023

View reviewed changes

jrhee17 reviewed Sep 5, 2023

View reviewed changes

tomatophobia added 6 commits October 7, 2023 00:04

Merge branch 'main' into add-web-test-client

099ab82

Rename WebTestClient to TestBlockingWebClient.

54714b5

Remove the byte array related methods.

7341b22

Remove infrequently used HTTP status assertion methods. Add an HTTP s…

2ffd15f

…tatus range assertion method.

Fix lint error

4d975cd

Add a test to verify API consistency.

d71e48e

minwoox modified the milestones: 1.26.0, 1.27.0 Oct 11, 2023

tomatophobia added 3 commits November 6, 2023 20:56

Merge branch 'main' into add-web-test-client

aab7d4e

Override contextHook method.

2c0884b

Fix lint error.

680a9a9

ikhoon modified the milestones: 1.27.0, 1.28.0 Jan 16, 2024

Merge branch 'main' into add-web-test-client

b97719a

jrhee17 reviewed Mar 26, 2024

View reviewed changes

jrhee17 modified the milestones: 1.28.0, 1.29.0 Apr 2, 2024

Merge branch 'main' into add-web-test-client

36daaa1

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add `WebTestClient` and `TestHttpResponse` to enable more fluent testing of HTTP responses #4740

Add `WebTestClient` and `TestHttpResponse` to enable more fluent testing of HTTP responses #4740

tomatophobia commented Mar 10, 2023 •

edited

ikhoon left a comment

ikhoon left a comment

ikhoon commented Jul 12, 2023

tomatophobia commented Jul 12, 2023 •

edited

tomatophobia left a comment

ikhoon Jul 27, 2023

tomatophobia Jul 28, 2023

ikhoon commented Jul 27, 2023

codecov bot commented Jul 28, 2023 •

edited

github-actions bot commented Aug 31, 2023 •

edited

jrhee17 left a comment •

edited

jrhee17 left a comment

jrhee17 Sep 5, 2023

tomatophobia Oct 6, 2023

jrhee17 Mar 26, 2024

jrhee17 Sep 5, 2023

tomatophobia Oct 6, 2023

jrhee17 Mar 26, 2024

jrhee17 left a comment

jrhee17 Mar 26, 2024

jrhee17 Mar 26, 2024

jrhee17 Mar 26, 2024

jrhee17 Mar 26, 2024

jrhee17 Mar 26, 2024

jrhee17 Mar 26, 2024

jrhee17 Mar 26, 2024

jrhee17 Mar 26, 2024

jrhee17 Mar 26, 2024

jrhee17 Mar 26, 2024

	public TestHttpResponse stringContains(Charset charset, String expected) {
	public TestHttpResponse containsString(Charset charset, String expected) {

	public TestHttpResponse contains(CharSequence name, String value) {
	public TestHttpResponse contains(CharSequence name, Object value) {

	public ThrowableAssert assertCause() {
	public ThrowableAssert assertThrowable() {

Add WebTestClient and TestHttpResponse to enable more fluent testing of HTTP responses #4740

Are you sure you want to change the base?

Add WebTestClient and TestHttpResponse to enable more fluent testing of HTTP responses #4740

Conversation

tomatophobia commented Mar 10, 2023 • edited

ikhoon left a comment

Choose a reason for hiding this comment

ikhoon left a comment

Choose a reason for hiding this comment

ikhoon commented Jul 12, 2023

tomatophobia commented Jul 12, 2023 • edited

tomatophobia left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ikhoon commented Jul 27, 2023

codecov bot commented Jul 28, 2023 • edited

Codecov Report

github-actions bot commented Aug 31, 2023 • edited

🔍 Build Scan® (commit: 36daaa1)

jrhee17 left a comment • edited

Choose a reason for hiding this comment

jrhee17 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jrhee17 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Add `WebTestClient` and `TestHttpResponse` to enable more fluent testing of HTTP responses #4740

Add `WebTestClient` and `TestHttpResponse` to enable more fluent testing of HTTP responses #4740

tomatophobia commented Mar 10, 2023 •

edited

tomatophobia commented Jul 12, 2023 •

edited

codecov bot commented Jul 28, 2023 •

edited

github-actions bot commented Aug 31, 2023 •

edited

🔍 Build Scan® (commit: `36daaa1`)

jrhee17 left a comment •

edited