Fix cross references

This commit is contained in:
Rob Winch
2023-04-19 10:26:17 -05:00
committed by rstoyanchev
parent 6b341ddf19
commit 139cde47e2
296 changed files with 1505 additions and 1505 deletions

View File

@@ -2,11 +2,11 @@
= Async Requests
This section shows how to use MockMvc on its own to test asynchronous request handling.
If using MockMvc through the <<webtestclient>>, there is nothing special to do to make
If using MockMvc through the xref:testing/webtestclient.adoc[WebTestClient], there is nothing special to do to make
asynchronous requests work as the `WebTestClient` automatically does what is described
in this section.
Servlet asynchronous requests, <<web.adoc#mvc-ann-async,supported in Spring MVC>>,
Servlet asynchronous requests, xref:web/webmvc/mvc-ann-async.adoc[supported in Spring MVC],
work by exiting the Servlet container thread and allowing the application to compute
the response asynchronously, after which an async dispatch is made to complete
processing on a Servlet container thread.

View File

@@ -1,7 +1,7 @@
[[spring-mvc-test-server-htmlunit]]
= HtmlUnit Integration
Spring provides integration between <<spring-mvc-test-server, MockMvc>> and
Spring provides integration between xref:testing/spring-mvc-test-framework/server.adoc[MockMvc] and
https://htmlunit.sourceforge.io/[HtmlUnit]. This simplifies performing end-to-end testing
when using HTML-based views. This integration lets you:

View File

@@ -8,7 +8,7 @@ use https://www.gebish.org/[Geb] to make our tests even Groovy-er.
== Why Geb and MockMvc?
Geb is backed by WebDriver, so it offers many of the
<<spring-mvc-test-server-htmlunit-webdriver-why, same benefits>> that we get from
xref:testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc#spring-mvc-test-server-htmlunit-webdriver-why[same benefits] that we get from
WebDriver. However, Geb makes things even easier by taking care of some of the
boilerplate code for us.
@@ -28,7 +28,7 @@ def setup() {
----
NOTE: This is a simple example of using `MockMvcHtmlUnitDriverBuilder`. For more advanced
usage, see <<spring-mvc-test-server-htmlunit-webdriver-advanced-builder>>.
usage, see xref:testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc#spring-mvc-test-server-htmlunit-webdriver-advanced-builder[Advanced `MockMvcHtmlUnitDriverBuilder`].
This ensures that any URL referencing `localhost` as the server is directed to our
`MockMvc` instance without the need for a real HTTP connection. Any other URL is
@@ -62,7 +62,7 @@ forwarded to the current page object. This removes a lot of the boilerplate code
needed when using WebDriver directly.
As with direct WebDriver usage, this improves on the design of our
<<spring-mvc-test-server-htmlunit-mah-usage, HtmlUnit test>> by using the Page Object
xref:testing/spring-mvc-test-framework/server-htmlunit/mah.adoc#spring-mvc-test-server-htmlunit-mah-usage[HtmlUnit test] by using the Page Object
Pattern. As mentioned previously, we can use the Page Object Pattern with HtmlUnit and
WebDriver, but it is even easier with Geb. Consider our new Groovy-based
`CreateMessagePage` implementation:

View File

@@ -41,7 +41,7 @@ We can easily create an HtmlUnit `WebClient` that integrates with MockMvc by usi
----
NOTE: This is a simple example of using `MockMvcWebClientBuilder`. For advanced usage,
see <<spring-mvc-test-server-htmlunit-mah-advanced-builder>>.
see xref:testing/spring-mvc-test-framework/server-htmlunit/mah.adoc#spring-mvc-test-server-htmlunit-mah-advanced-builder[Advanced `MockMvcWebClientBuilder`].
This ensures that any URL that references `localhost` as the server is directed to our
`MockMvc` instance without the need for a real HTTP connection. Any other URL is
@@ -68,7 +68,7 @@ message with the following:
----
NOTE: The default context path is `""`. Alternatively, we can specify the context path,
as described in <<spring-mvc-test-server-htmlunit-mah-advanced-builder>>.
as described in xref:testing/spring-mvc-test-framework/server-htmlunit/mah.adoc#spring-mvc-test-server-htmlunit-mah-advanced-builder[Advanced `MockMvcWebClientBuilder`].
Once we have a reference to the `HtmlPage`, we can then fill out the form and submit it
to create a message, as the following example shows:
@@ -123,7 +123,7 @@ assertions use the https://assertj.github.io/doc/[AssertJ] library:
----
The preceding code improves on our
<<spring-mvc-test-server-htmlunit-mock-mvc-test, MockMvc test>> in a number of ways.
xref:testing/spring-mvc-test-framework/server-htmlunit/why.adoc#spring-mvc-test-server-htmlunit-mock-mvc-test[MockMvc test] in a number of ways.
First, we no longer have to explicitly verify our form and then create a request that
looks like the form. Instead, we request the form, fill it out, and submit it, thereby
significantly reducing the overhead.
@@ -238,5 +238,5 @@ This is more verbose, but, by building the `WebClient` with a `MockMvc` instance
the full power of MockMvc at our fingertips.
TIP: For additional information on creating a `MockMvc` instance, see
<<spring-mvc-test-server-setup-options>>.
xref:testing/spring-mvc-test-framework/server-setup-options.adoc[Setup Choices].

View File

@@ -180,7 +180,7 @@ We can easily create a Selenium WebDriver that integrates with MockMvc by using
----
NOTE: This is a simple example of using `MockMvcHtmlUnitDriverBuilder`. For more advanced
usage, see <<spring-mvc-test-server-htmlunit-webdriver-advanced-builder>>.
usage, see xref:testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc#spring-mvc-test-server-htmlunit-webdriver-advanced-builder[Advanced `MockMvcHtmlUnitDriverBuilder`].
The preceding example ensures that any URL that references `localhost` as the server is
directed to our `MockMvc` instance without the need for a real HTTP connection. Any other
@@ -226,9 +226,9 @@ We can then fill out the form and submit it to create a message, as follows:
----
--
This improves on the design of our <<spring-mvc-test-server-htmlunit-mah-usage, HtmlUnit test>>
This improves on the design of our xref:testing/spring-mvc-test-framework/server-htmlunit/mah.adoc#spring-mvc-test-server-htmlunit-mah-usage[HtmlUnit test]
by leveraging the Page Object Pattern. As we mentioned in
<<spring-mvc-test-server-htmlunit-webdriver-why>>, we can use the Page Object Pattern
xref:testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc#spring-mvc-test-server-htmlunit-webdriver-why[Why WebDriver and MockMvc?], we can use the Page Object Pattern
with HtmlUnit, but it is much easier with WebDriver. Consider the following
`CreateMessagePage` implementation:
@@ -499,5 +499,5 @@ This is more verbose, but, by building the `WebDriver` with a `MockMvc` instance
the full power of MockMvc at our fingertips.
TIP: For additional information on creating a `MockMvc` instance, see
<<spring-mvc-test-server-setup-options>>.
xref:testing/spring-mvc-test-framework/server-setup-options.adoc[Setup Choices].

View File

@@ -177,11 +177,11 @@ with HtmlUnit.`"
You have a number of options when you want to integrate MockMvc with HtmlUnit:
* <<spring-mvc-test-server-htmlunit-mah,MockMvc and HtmlUnit>>: Use this option if you
* xref:testing/spring-mvc-test-framework/server-htmlunit/mah.adoc[MockMvc and HtmlUnit]: Use this option if you
want to use the raw HtmlUnit libraries.
* <<spring-mvc-test-server-htmlunit-webdriver,MockMvc and WebDriver>>: Use this option to
* xref:testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc[MockMvc and WebDriver]: Use this option to
ease development and reuse code between integration and end-to-end testing.
* <<spring-mvc-test-server-htmlunit-geb,MockMvc and Geb>>: Use this option if you want to
* xref:testing/spring-mvc-test-framework/server-htmlunit/geb.adoc[MockMvc and Geb]: Use this option if you want to
use Groovy for testing, ease development, and reuse code between integration and
end-to-end testing.

View File

@@ -3,7 +3,7 @@
This section shows how to use MockMvc on its own to perform requests and verify responses.
If using MockMvc through the `WebTestClient` please see the corresponding section on
<<webtestclient-tests>> instead.
xref:testing/webtestclient.adoc#webtestclient-tests[Writing Tests] instead.
To perform requests that use any HTTP method, as the following example shows:

View File

@@ -42,7 +42,7 @@ To set up MockMvc for testing a specific controller, use the following:
----
Or you can also use this setup when testing through the
<<webtestclient-controller-config, WebTestClient>> which delegates to the same builder
xref:testing/webtestclient.adoc#webtestclient-controller-config[WebTestClient] which delegates to the same builder
as shown above.
To set up MockMvc through Spring configuration, use the following:
@@ -84,7 +84,7 @@ To set up MockMvc through Spring configuration, use the following:
----
Or you can also use this setup when testing through the
<<webtestclient-context-config, WebTestClient>> which delegates to the same builder
xref:testing/webtestclient.adoc#webtestclient-context-config[WebTestClient] which delegates to the same builder
as shown above.

View File

@@ -11,7 +11,7 @@ When using MockMvc directly to perform requests, you'll need static imports for:
An easy way to remember that is search for `MockMvc*`. If using Eclipse be sure to also
add the above as "`favorite static members`" in the Eclipse preferences.
When using MockMvc through the <<webtestclient>> you do not need static imports.
When using MockMvc through the xref:testing/webtestclient.adoc[WebTestClient] you do not need static imports.
The `WebTestClient` provides a fluent API without static imports.

View File

@@ -10,14 +10,14 @@ do they involve any of the supporting `@InitBinder`, `@ModelAttribute`, or
The Spring MVC Test framework, also known as `MockMvc`, aims to provide more complete
testing for Spring MVC controllers without a running server. It does that by invoking
the `DispatcherServlet` and passing
<<mock-objects-servlet, "`mock`" implementations of the Servlet API>> from the
xref:testing/unit.adoc#mock-objects-servlet["`mock`" implementations of the Servlet API] from the
`spring-test` module which replicates the full Spring MVC request handling without
a running server.
MockMvc is a server side test framework that lets you verify most of the functionality
of a Spring MVC application using lightweight and targeted tests. You can use it on
its own to perform requests and to verify responses, or you can also use it through
the <<webtestclient>> API with MockMvc plugged in as the server to handle requests
the xref:testing/webtestclient.adoc[WebTestClient] API with MockMvc plugged in as the server to handle requests
with.