diff --git a/framework-docs/modules/ROOT/pages/testing/mockmvc.adoc b/framework-docs/modules/ROOT/pages/testing/mockmvc.adoc index 891a1f1c2c..ac42f4be5e 100644 --- a/framework-docs/modules/ROOT/pages/testing/mockmvc.adoc +++ b/framework-docs/modules/ROOT/pages/testing/mockmvc.adoc @@ -5,12 +5,12 @@ MockMvc provides support for testing Spring MVC applications. It performs full Spring MVC request handling but via mock request and response objects instead of a running server. -MockMvc can be used on its own to perform requests and verify responses responses using -Hamcrest, or through `MockMvcTester` that provides a fluent API using AssertJ. Finally, -it can also be used through the xref:testing/webtestclient.adoc[WebTestClient] where -MockMvc is plugged in as the server to handle requests with. The advantage of -`WebTestClient` is the option to work with higher level objects instead of raw data as -well as the ability to switch to full, end-to-end HTTP tests against a live server and -use the same test API. +MockMvc can be used on its own to perform requests and verify responses using Hamcrest or +through `MockMvcTester` which provides a fluent API using AssertJ. It can also be used +through the xref:testing/webtestclient.adoc[WebTestClient] where MockMvc is plugged in as +the server to handle requests. The advantage of using `WebTestClient` is that it provides +you the option of working with higher level objects instead of raw data as well as the +ability to switch to full, end-to-end HTTP tests against a live server and use the same +test API. diff --git a/framework-docs/modules/ROOT/pages/testing/mockmvc/overview.adoc b/framework-docs/modules/ROOT/pages/testing/mockmvc/overview.adoc index f28fb27d94..a1571c1bd9 100644 --- a/framework-docs/modules/ROOT/pages/testing/mockmvc/overview.adoc +++ b/framework-docs/modules/ROOT/pages/testing/mockmvc/overview.adoc @@ -4,21 +4,21 @@ You can write plain unit tests for Spring MVC by instantiating a controller, injecting it with dependencies, and calling its methods. However such tests do not verify request -mappings, data binding, message conversion, type conversion, validation, and nor -do they involve any of the supporting `@InitBinder`, `@ModelAttribute`, or +mappings, data binding, message conversion, type conversion, or validation and also do +not involve any of the supporting `@InitBinder`, `@ModelAttribute`, or `@ExceptionHandler` methods. -`MockMvc` aims to provide more complete testing for Spring MVC controllers without a -running server. It does that by invoking the `DispatcherServlet` and passing -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` aims to provide more complete testing support for Spring MVC controllers +without a running server. It does that by invoking the `DispatcherServlet` and passing +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 using Hamcrest, or through -`MockMvcTester` that provides a fluent API using AssertJ. Finally, you can also use it -through the xref:testing/webtestclient.adoc[WebTestClient] API with MockMvc plugged in -as the server to handle requests with. +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 using Hamcrest or through `MockMvcTester` +which provides a fluent API using AssertJ. You can also use it through the +xref:testing/webtestclient.adoc[WebTestClient] API with MockMvc plugged in as the server +to handle requests. diff --git a/framework-docs/modules/ROOT/pages/testing/mockmvc/resources.adoc b/framework-docs/modules/ROOT/pages/testing/mockmvc/resources.adoc index a3fa509fcd..f749cead6f 100644 --- a/framework-docs/modules/ROOT/pages/testing/mockmvc/resources.adoc +++ b/framework-docs/modules/ROOT/pages/testing/mockmvc/resources.adoc @@ -2,7 +2,7 @@ = Further Examples :page-section-summary-toc: 1 -The framework's own tests include +The framework's own test suite includes {spring-framework-code}/spring-test/src/test/java/org/springframework/test/web/servlet/samples[ many sample tests] intended to show how to use MockMvc on its own or through the {spring-framework-code}/spring-test/src/test/java/org/springframework/test/web/servlet/samples/client[ diff --git a/framework-docs/modules/ROOT/pages/testing/mockmvc/setup-options.adoc b/framework-docs/modules/ROOT/pages/testing/mockmvc/setup-options.adoc index b2445f8887..5a12a668c5 100644 --- a/framework-docs/modules/ROOT/pages/testing/mockmvc/setup-options.adoc +++ b/framework-docs/modules/ROOT/pages/testing/mockmvc/setup-options.adoc @@ -1,28 +1,31 @@ [[mockmvc-server-setup-options]] = Setup Options -MockMvc can be setup in one of two ways. One is to point directly to the controllers you -want to test and programmatically configure Spring MVC infrastructure. The second is to -point to Spring configuration with Spring MVC and controller infrastructure in it. +MockMvc can be set up in one of two ways. + +`WebApplicationContext` :: + Point to Spring configuration with Spring MVC and controller infrastructure in it. +Standalone :: + Point directly to the controllers you want to test and programmatically configure Spring + MVC infrastructure. Which setup option should you use? -The use of an `ApplicationContext` loads your actual Spring MVC configuration, resulting -The `WebApplicationContext`-based test loads your actual Spring MVC configuration, -resulting in a more complete integration test. Since the TestContext framework caches -the loaded Spring configuration, it helps keep tests running fast, even as you introduce -more tests in your test suite using the same configuration. Furthermore, you can -override services used by your controller using `@MockitoBean` to remain focused on +A `WebApplicationContext`-based test loads your actual Spring MVC configuration, +resulting in a more complete integration test. Since the TestContext framework caches the +loaded Spring configuration, it helps keep tests running fast, even as you introduce more +tests in your test suite using the same configuration. Furthermore, you can override +services used by your controller using `@MockitoBean` or `@TestBean` to remain focused on testing the web layer. -The standalone test, on the other hand, is a little closer to a unit test. It tests one +A standalone test, on the other hand, is a little closer to a unit test. It tests one controller at a time. You can manually inject the controller with mock dependencies, and it does not involve loading Spring configuration. Such tests are more focused on style and make it easier to see which controller is being tested, whether any specific Spring MVC configuration is required to work, and so on. The standalone setup is also a very convenient way to write ad-hoc tests to verify specific behavior or to debug an issue. -As with most "`integration versus unit testing`" debates, there is no right or wrong +As with most "integration versus unit testing" debates, there is no right or wrong answer. However, using standalone tests does imply the need for additional integration tests to verify your Spring MVC configuration. Alternatively, you can write all your tests with a `WebApplicationContext`, so that they always test against your actual Spring diff --git a/framework-docs/modules/ROOT/pages/testing/mockmvc/vs-end-to-end-integration-tests.adoc b/framework-docs/modules/ROOT/pages/testing/mockmvc/vs-end-to-end-integration-tests.adoc index cbe8604974..46a8a8f345 100644 --- a/framework-docs/modules/ROOT/pages/testing/mockmvc/vs-end-to-end-integration-tests.adoc +++ b/framework-docs/modules/ROOT/pages/testing/mockmvc/vs-end-to-end-integration-tests.adoc @@ -10,12 +10,12 @@ The easiest way to think about this is by starting with a blank `MockHttpServlet Whatever you add to it is what the request becomes. Things that may catch you by surprise are that there is no context path by default; no `jsessionid` cookie; no forwarding, error, or async dispatches; and, therefore, no actual JSP rendering. Instead, -"`forwarded`" and "`redirected`" URLs are saved in the `MockHttpServletResponse` and can +"forwarded" and "redirected" URLs are saved in the `MockHttpServletResponse` and can be asserted with expectations. This means that, if you use JSPs, you can verify the JSP page to which the request was forwarded, but no HTML is rendered. In other words, the JSP is not invoked. Note, -however, that all other rendering technologies that do not rely on forwarding, such as +however, that all other rendering technologies which do not rely on forwarding, such as Thymeleaf and Freemarker, render HTML to the response body as expected. The same is true for rendering JSON, XML, and other formats through `@ResponseBody` methods. @@ -30,17 +30,17 @@ testing, but they are a little closer to it. For example, you can isolate the we by injecting mocked services into controllers, in which case you are testing the web layer only through the `DispatcherServlet` but with actual Spring configuration, as you might test the data access layer in isolation from the layers above it. Also, you can use -the stand-alone setup, focusing on one controller at a time and manually providing the +the standalone setup, focusing on one controller at a time and manually providing the configuration required to make it work. Another important distinction when using Spring MVC Test is that, conceptually, such -tests are the server-side, so you can check what handler was used, if an exception was -handled with a HandlerExceptionResolver, what the content of the model is, what binding +tests are server-side tests, so you can check what handler was used, if an exception was +handled with a `HandlerExceptionResolver`, what the content of the model is, what binding errors there were, and other details. That means that it is easier to write expectations, since the server is not an opaque box, as it is when testing it through an actual HTTP -client. This is generally an advantage of classic unit testing: It is easier to write, +client. This is generally an advantage of classic unit testing: it is easier to write, reason about, and debug but does not replace the need for full integration tests. At the same time, it is important not to lose sight of the fact that the response is the most -important thing to check. In short, there is room here for multiple styles and strategies +important thing to check. In short, there is room for multiple styles and strategies of testing even within the same project.