`WebTestClient` is a thin shell around <<web-reactive.adoc#webflux-webclient, WebClient>>,
`WebTestClient` is a thin shell around <<web-reactive.adoc#webflux-client, WebClient>>,
using it to perform requests and exposing a dedicated, fluent API for verifying responses.
`WebTestClient` binds to a WebFlux application by using a
<<testing.adoc#mock-objects-web-reactive,mock request and response>>, or it can test any
@ -140,9 +140,9 @@ are readily available following `bindToServer`. For all others, you need to use
@@ -140,9 +140,9 @@ are readily available following `bindToServer`. For all others, you need to use
[[webtestclient-tests]]
== Writing Tests
`WebTestClient` is a thin shell around <<web-reactive.adoc#webflux-webclient,WebClient>>.
It provides an identical API up to the point of performing a request by using `exchange()`.
What follows after `exchange()` is a chained API workflow to verify responses.
`WebTestClient` provides an API identical to <<web-reactive.adoc#webflux-client,WebClient>>
up to the point of performing a request by using `exchange()`. What follows after
`exchange()` is a chained API workflow to verify responses.
Typically, you start by asserting the response status and headers, as follows:
@ -1406,7 +1406,7 @@ example, you can create a custom `@EnabledOnMac` annotation as follows:
@@ -1406,7 +1406,7 @@ example, you can create a custom `@EnabledOnMac` annotation as follows:
`@DisabledIf` is used to signal that the annotated JUnit Jupiter test class or test
@ -1627,8 +1627,9 @@ configuration of individual JUnit Jupiter based test methods, as follows:
@@ -1627,8 +1627,9 @@ configuration of individual JUnit Jupiter based test methods, as follows:
----
====
For further details, see the <<core.adoc#annotation-programming-model,Spring
@ -1670,9 +1671,8 @@ in turn, manages a `TestContext` that holds the context of the current test. The
@@ -1670,9 +1671,8 @@ in turn, manages a `TestContext` that holds the context of the current test. The
and delegates to `TestExecutionListener` implementations, which instrument the actual
test execution by providing dependency injection, managing transactions, and so on. A
`SmartContextLoader` is responsible for loading an `ApplicationContext` for a given test
class. See the {api-spring-framework}[Javadoc] and the Spring test suite for further
information and examples of various implementations.
class. See the {api-spring-framework}/test/context/package-summary.html[Javadoc] and the
Spring test suite for further information and examples of various implementations.
===== `TestContext`
@ -3860,7 +3860,7 @@ of `PlatformTransactionManager` within the test's `ApplicationContext`, you can
@@ -3860,7 +3860,7 @@ of `PlatformTransactionManager` within the test's `ApplicationContext`, you can
qualifier by using `@Transactional("myTxMgr")` or `@Transactional(transactionManager =
"myTxMgr")`, or `TransactionManagementConfigurer` can be implemented by an
for `TestContextTransactionUtils.retrieveTransactionManager()`] for details on the
algorithm used to look up a transaction manager in the test's `ApplicationContext`.
@ -5295,8 +5295,8 @@ when using HTML-based views. This integration lets you:
@@ -5295,8 +5295,8 @@ when using HTML-based views. This integration lets you:
* Easily test HTML pages by using tools such as
http://htmlunit.sourceforge.net/[HtmlUnit],
http://seleniumhq.org/projects/webdriver/[WebDriver], and
http://www.gebish.org/manual/current/testing.html#spock_junit__testng[Geb] without the
need to deploy to a Servlet container.
http://www.gebish.org/manual/current/#spock-junit-testng[Geb] without the need to
deploy to a Servlet container.
* Test JavaScript within pages.
* Optionally, test using mock services to speed up testing.
* Share logic between in-container end-to-end tests and out-of-container integration tests.