From a1053d43644b9c0cd1a40f72a9437d16621b516f Mon Sep 17 00:00:00 2001 From: Sam Brannen Date: Wed, 12 Dec 2012 00:56:26 +0100 Subject: [PATCH] Document WebApplicationContext support in the TCF This commit adds documentation for the following new features in the Spring TestContext Framework within the Testing chapter of the reference manual. - @WebAppConfiguration and context caching - WebDelegatingSmartContextLoader - AnnotationConfigWebContextLoader - GenericXmlWebContextLoader - Loading a WebApplicationContext in integration tests - ServletTestExecutionListener - Testing request and session scoped beans Issue: SPR-9864 --- src/reference/docbook/testing.xml | 653 +++++++++++++++++++++++++----- 1 file changed, 547 insertions(+), 106 deletions(-) diff --git a/src/reference/docbook/testing.xml b/src/reference/docbook/testing.xml index 1ff24f9baab..2e1ec6f6341 100644 --- a/src/reference/docbook/testing.xml +++ b/src/reference/docbook/testing.xml @@ -265,15 +265,16 @@ Context management and caching The Spring TestContext Framework provides consistent loading of - Spring ApplicationContexts and caching of those - contexts. Support for the caching of loaded contexts is important, - because startup time can become an issue — not because of the overhead - of Spring itself, but because the objects instantiated by the Spring - container take time to instantiate. For example, a project with 50 to - 100 Hibernate mapping files might take 10 to 20 seconds to load the - mapping files, and incurring that cost before running every test in - every test fixture leads to slower overall test runs that reduce - developer productivity. + Spring ApplicationContexts and + WebApplicationContexts as well as caching of + those contexts. Support for the caching of loaded contexts is + important, because startup time can become an issue — not because of + the overhead of Spring itself, but because the objects instantiated by + the Spring container take time to instantiate. For example, a project + with 50 to 100 Hibernate mapping files might take 10 to 20 seconds to + load the mapping files, and incurring that cost before running every + test in every test fixture leads to slower overall test runs that + reduce developer productivity. Test classes typically declare either an array of resource locations for XML configuration metadata @@ -526,6 +527,55 @@ public class CustomLoaderXmlApplicationContextTests { details. + + @WebAppConfiguration + + A class-level annotation that is used to declare that the + ApplicationContext loaded for an + integration test should be a + WebApplicationContext. The mere + presence of @WebAppConfiguration on + a test class ensures that a + WebApplicationContext will be + loaded for the test, using the default value of + "file:src/main/webapp" for the path to the root + of the web application (i.e., the resource base + path). The resource base path is used behind the scenes + to create a MockServletContext which serves + as the ServletContext for the + test's + WebApplicationContext. + + @ContextConfiguration +@WebAppConfiguration +public class WebAppTests { + // class body... +} + + To override the default, specify a different base resource + path via the implicit + value attribute. Both + classpath: and file: + resource prefixes are supported. If no resource prefix is supplied + the path is assumed to be a file system resource. + + @ContextConfiguration +@WebAppConfiguration("classpath:test-web-resources") +public class WebAppTests { + // class body... +} + + Note that + @WebAppConfiguration must be used + in conjunction with + @ContextConfiguration, either + within a single test class or within a test class hierarchy. See + the Javadoc for + @WebAppConfiguration for further + details. + + @ActiveProfiles @@ -1107,14 +1157,16 @@ public void testProcessRepeatedly() { TestContextManager with which the listener is registered. - Spring provides three + Spring provides four TestExecutionListener implementations that are configured by default: + ServletTestExecutionListener, DependencyInjectionTestExecutionListener, DirtiesContextTestExecutionListener, and TransactionalTestExecutionListener. - Respectively, they support dependency injection of the test - instance, handling of the + Respectively, they support Servlet API mocks for a + WebApplicationContext, dependency + injection of the test instance, handling of the @DirtiesContext annotation, and transactional test execution with default rollback semantics. @@ -1142,18 +1194,18 @@ public void testProcessRepeatedly() { supersedes the ContextLoader SPI that was introduced in Spring 2.5. Specifically, a SmartContextLoader can choose to - process either resource locations or annotated - classes. Furthermore, a + process resource locations, annotated + classes, or context + initializers. Furthermore, a SmartContextLoader can set active bean definition profiles in the context that it loads. - Spring provides the following out-of-the-box - implementations: + Spring provides the following implementations: - DelegatingSmartContextLoader: the - default loader which delegates internally to an + DelegatingSmartContextLoader: one + of two default loaders which delegates internally to an AnnotationConfigContextLoader or a GenericXmlContextLoader depending either on the configuration declared for the test class or on @@ -1162,21 +1214,48 @@ public void testProcessRepeatedly() { - AnnotationConfigContextLoader: - loads an application context from annotated - classes. + WebDelegatingSmartContextLoader: + one of two default loaders which delegates internally to an + AnnotationConfigWebContextLoader or a + GenericXmlWebContextLoader depending + either on the configuration declared for the test class or on + the presence of default locations or default configuration + classes. A web ContextLoader + will only be used if + @WebAppConfiguration is present + on the test class. - GenericXmlContextLoader: loads an - application context from XML resource - locations. + AnnotationConfigContextLoader: + loads a standard + ApplicationContext from + annotated classes. + + + + AnnotationConfigWebContextLoader: + loads a WebApplicationContext + from annotated classes. + + + + GenericXmlContextLoader: loads a + standard ApplicationContext + from XML resource locations. + + + + GenericXmlWebContextLoader: loads + a WebApplicationContext from + XML resource locations. GenericPropertiesContextLoader: - loads an application context from Java Properties - files. + loads a standard + ApplicationContext from Java + Properties files. @@ -1194,8 +1273,8 @@ public void testProcessRepeatedly() { Each TestContext provides context management and caching support for the test instance it is responsible for. Test instances do not automatically receive access to the - configured ApplicationContext. However, if a - test class implements the + configured ApplicationContext. However, + if a test class implements the ApplicationContextAware interface, a reference to the ApplicationContext is supplied to the test instance. Note that @@ -1203,7 +1282,7 @@ public void testProcessRepeatedly() { AbstractTestNGSpringContextTests implement ApplicationContextAware and therefore provide access to the ApplicationContext - out-of-the-box. + automatically. @Autowired ApplicationContext @@ -1221,6 +1300,21 @@ public class MyTest { @Autowired private ApplicationContext applicationContext; + // class body... +} + + Similarly, if your test is configured to load a + WebApplicationContext, you can inject + the web application context into your test as follows: + + @RunWith(SpringJUnit4ClassRunner.class) +@WebAppConfiguration +@ContextConfiguration +public class MyWebAppTest { + + @Autowired + private WebApplicationContext wac; + // class body... } @@ -1781,12 +1875,207 @@ public class TransferServiceTest { +
+ Loading a WebApplicationContext + + Spring 3.2 introduces support for loading a + WebApplicationContext in integration + tests. To instruct the TestContext framework to load a + WebApplicationContext instead of a + standard ApplicationContext, simply + annotate the respective test class with + @WebAppConfiguration. + + The presence of + @WebAppConfiguration on your test + class instructs the TestContext framework (TCF) that a + WebApplicationContext (WAC) should be + loaded for your integration tests. In the background the TCF makes + sure that a MockServletContext is + created and supplied to your test's WAC. By default the base + resource path for your + MockServletContext will be set to + "src/main/webapp". This is interpreted as a + path relative to the root of your JVM (i.e., normally the path to + your project). If you're familiar with the directory structure of a + web application in a Maven project, you'll know that + "src/main/webapp" is the default location for + the root of your WAR. If you need to override this default, simply + provide an alternate path to the + @WebAppConfiguration annotation + (e.g., + @WebAppConfiguration("src/test/webapp")). + If you wish to reference a base resource path from the classpath + instead of the file system, just use Spring's + classpath: prefix. + + Please note that Spring's testing support for + WebApplicationContexts is on par with + its support for standard + ApplicationContexts. When testing + with a WebApplicationContext you are + free to declare either XML configuration files or + @Configuration classes via + @ContextConfiguration. You are of + course also free to use any other test annotations such as + @TestExecutionListeners, + @TransactionConfiguration, + @ActiveProfiles, etc. + + The following examples demonstrate some of the various + configuration options for loading a + WebApplicationContext. + + + Conventions + + @RunWith(SpringJUnit4ClassRunner.class) + +// defaults to "file:src/main/webapp" +@WebAppConfiguration + +// detects "WacTests-context.xml" in same package +// or static nested @Configuration class +@ContextConfiguration + +public class WacTests { + //... +} + + + The above example demonstrates the TestContext framework's + support for convention over configuration. If + you annotate a test class with + @WebAppConfiguration without + specifying a resource base path, the resource path will effectively + default to "file:src/main/webapp". Similarly, + if you declare @ContextConfiguration + without specifying resource + locations, annotated + classes, or context + initializers, Spring will attempt to + detect the presence of your configuration using conventions (i.e., + "WacTests-context.xml" in the same package as + the WacTests class or static nested + @Configuration classes). + + + Default Resource Semantics + + @RunWith(SpringJUnit4ClassRunner.class) + +// file system resource +@WebAppConfiguration("webapp") + +// classpath resource +@ContextConfiguration("/spring/test-servlet-config.xml") + +public class WacTests { + //... +} + + + This example demonstrates how to explicitly declare a resource + base path with @WebAppConfiguration + and an XML resource location with + @ContextConfiguration. The important + thing to note here is the different semantics for paths with these + two annotations. By default, + @WebAppConfiguration resource paths + are file system based; whereas, + @ContextConfiguration resource + locations are classpath based. + + + Explicit Resource Semantics + + @RunWith(SpringJUnit4ClassRunner.class) + +// classpath resource +@WebAppConfiguration("classpath:test-web-resources") + +// file system resource +@ContextConfiguration("file:src/main/webapp/WEB-INF/servlet-config.xml") + +public class WacTests { + //... +} + + + In this third example, we see that we can override the default + resource semantics for both annotations by specifying a Spring + resource prefix. Contrast the comments in this example with the + previous example. + +
+ Working with Web Mocks + + To provide comprehensive web testing support, Spring 3.2 + introduces a new + ServletTestExecutionListener that + is enabled by default. When testing against a + WebApplicationContext this TestExecutionListener + sets up default thread-local state via Spring Web's + RequestContextHolder before each + test method and creates a + MockHttpServletRequest, + MockHttpServletResponse, and + ServletWebRequest based on the base + resource path configured via + @WebAppConfiguration. + ServletTestExecutionListener also + ensures that the + MockHttpServletResponse and + ServletWebRequest can be injected + into the test instance, and once the test is complete it cleans up + thread-local state. + + Once you have a + WebApplicationContext loaded for + your test you might find that you need to interact with the web + mocks — for example, to set up your test fixture or to perform + assertions after invoking your web component. The following + example demonstrates which mocks can be autowired into your test + instance. Note that the + WebApplicationContext and + MockServletContext are both cached + across the test suite; whereas, the other mocks are managed per + test method by the + ServletTestExecutionListener. + + + Injecting Mocks + + @WebAppConfiguration +@ContextConfiguration +public class WacTests { + + @Autowired WebApplicationContext wac; // cached + + @Autowired MockServletContext servletContext; // cached + + @Autowired MockHttpSession session; + + @Autowired MockHttpServletRequest request; + + @Autowired MockHttpServletResponse response; + + @Autowired ServletWebRequest webRequest; + + //... +} + +
+
+
Context caching Once the TestContext framework loads an - ApplicationContext for a test, that - context will be cached and reused for ApplicationContext (or + WebApplicationContext) for a test, + that context will be cached and reused for all subsequent tests that declare the same unique context configuration within the same test suite. To understand how caching works, it is important to understand what is @@ -1826,6 +2115,11 @@ public class TransferServiceTest { activeProfiles (from @ActiveProfiles) + + + resourceBasePath (from + @WebAppConfiguration) + For example, if TestClassA specifies @@ -1838,7 +2132,8 @@ public class TransferServiceTest { solely on those locations. So if TestClassB also defines {"app-config.xml", "test-config.xml"} for its locations (either explicitly or - implicitly through inheritance) and does not define a different + implicitly through inheritance) but does not define + @WebAppConfiguration, a different ContextLoader, different active profiles, or different context initializers, then the same ApplicationContext will be shared by @@ -2055,6 +2350,170 @@ public class HibernateTitleRepositoryTests {
+
+ Testing request and session scoped beans + + Request and session + scoped beans have been supported by Spring for several years + now, but it's always been a bit non-trivial to test them. As of Spring + 3.2 it's now a breeze to test your request-scoped and session-scoped + beans by following these steps. + + + + Ensure that a + WebApplicationContext is loaded for + your test by annotating your test class with + @WebAppConfiguration. + + + + Inject the mock request or session into your test instance + and prepare your test fixture as appropriate. + + + + Invoke your web component that you retrieved from the + configured WebApplicationContext + (i.e., via dependency injection). + + + + Perform assertions against the mocks. + + + + The following code snippet displays the XML configuration for a + login use case. Note that the userService bean has + a dependency on a request-scoped loginAction bean. + Also, the LoginAction is instantiated using + SpEL expressions that retrieve the + username and password from the current HTTP request. In our test, we + will want to configure these request parameters via the mock managed + by the TestContext framework. + + + Request-scoped bean configuration + + <beans> + + <bean id="userService" + class="com.example.SimpleUserService" + c:loginAction-ref="loginAction" /> + + <bean id="loginAction" class="com.example.LoginAction" + c:username="#{request.getParameter('user')}" + c:password="#{request.getParameter('pswd')}" + scope="request"> + <aop:scoped-proxy /> + </bean> + +</beans> + + + In RequestScopedBeanTests we inject both + the UserService (i.e., the subject under test) + and the MockHttpServletRequest into our test + instance. Within our requestScope() test method + we set up our test fixture by setting request parameters in the + provided MockHttpServletRequest. When the + loginUser() method is invoked on our + userService we are assured that the user service + has access to the request-scoped loginAction for + the current MockHttpServletRequest (i.e., the + one we just set parameters in). We can then perform assertions against + the results based on the known inputs for the username and + password. + + + Request-scoped bean test + + @RunWith(SpringJUnit4ClassRunner.class) +@ContextConfiguration +@WebAppConfiguration +public class RequestScopedBeanTests { + + @Autowired UserService userService; + @Autowired MockHttpServletRequest request; + + @Test + public void requestScope() { + + request.setParameter("user", "enigma"); + request.setParameter("pswd", "$pr!ng"); + + LoginResults results = userService.loginUser(); + + // assert results + } +} + + + The following code snippet is similar to the one we saw above + for a request-scoped bean; however, this time the + userService bean has a dependency on a + session-scoped userPreferences bean. Note that the + UserPreferences bean is instantiated using a + SpEL expression that retrieves the theme from the + current HTTP session. In our test, we will need to configure a theme + in the mock session managed by the TestContext framework. + + + Session-scoped bean configuration + + <beans> + + <bean id="userService" + class="com.example.SimpleUserService" + c:userPreferences-ref="userPreferences" /> + + <bean id="userPreferences" + class="com.example.UserPreferences" + c:theme="#{session.getAttribute('theme')}" + scope="session"> + <aop:scoped-proxy /> + </bean> + +</beans> + + + In SessionScopedBeanTests we inject the + UserService and the + MockHttpSession into our test instance. Within + our sessionScope() test method we set up our test + fixture by setting the expected "theme" attribute in the provided + MockHttpSession. When the + processUserPreferences() method is invoked on our + userService we are assured that the user service + has access to the session-scoped userPreferences + for the current MockHttpSession, and we can + perform assertions against the results based on the configured + theme. + + + Session-scoped bean test + + @RunWith(SpringJUnit4ClassRunner.class) +@ContextConfiguration +@WebAppConfiguration +public class SessionScopedBeanTests { + + @Autowired UserService userService; + @Autowired MockHttpSession session; + + @Test + public void sessionScope() throws Exception { + + session.setAttribute("theme", "blue"); + + Results results = userService.processUserPreferences(); + + // assert results + } +} + +
+
Transaction management @@ -2420,10 +2879,10 @@ public class SimpleTest { The spring-test module uses a different package org.springframework.test.web but otherwise is nearly identical with two exceptions. One is support for - features new in 3.2 (e.g. async web requests). The other relates to - the options for creating a MockMvc instance. In - Spring Framework 3.2, this can only be done through the TestContext - framework, which provides caching benefits for the loaded + features new in 3.2 (e.g. asynchronous web requests). The other + relates to the options for creating a MockMvc + instance. In Spring Framework 3.2, this can only be done through the + TestContext framework, which provides caching benefits for the loaded configuration. @@ -2432,12 +2891,13 @@ public class SimpleTest { through a fluent API. Typically it loads the actual Spring configuration through the TestContext framework and always uses the DispatcherServlet to process requests thus - approximating full integration tests without requiring a running servlet + approximating full integration tests without requiring a running Servlet container. Client-side tests are RestTemplate-based - and allow tests for code that relies on the RestTemplate - without requiring a running server to respond to the requests. + and allow tests for code that relies on the + RestTemplate without requiring a running server + to respond to the requests.
Server-Side Tests @@ -2476,8 +2936,8 @@ public class SimpleTest { MockHttpServletResponse works, you'll know that forwards and redirects are not actually executed. Instead "forwarded" and "redirected" URLs are saved and can be asserted in tests. This - means if you are using JSPs, you can verify the JSP page to which the request was - forwarded. + means if you are using JSPs, you can verify the JSP page to which the + request was forwarded. All other means of rendering including @ResponseBody methods and @@ -2520,10 +2980,10 @@ public class ExampleTests { The test relies on the WebApplicationContext support of the TestContext framework. It loads Spring - configuration from an XML config file located in the same package as - the test class (also supports Java config) and injects the created - WebApplicationContext into the test so - a MockMvc instance can be created with + configuration from an XML configuration file located in the same + package as the test class (also supports JavaConfig) and injects the + created WebApplicationContext into the + test so a MockMvc instance can be created with it. The MockMvc is then used to perform a @@ -2589,7 +3049,7 @@ public class MyWebTests { without loading any Spring configuration. Instead basic Spring MVC configuration suitable for testing annotated controllers is automatically created. The created configuration is comparable to - that of the MVC Java config (and the MVC namespace) and can be + that of the MVC JavaConfig (and the MVC namespace) and can be customized to a degree through builder-style methods: public class MyWebTests { @@ -2616,8 +3076,7 @@ public class MyWebTests { remain focused on testing the web layer. Here is an example of declaring a mock service with Mockito: - -<bean id="accountService" class="org.mockito.Mockito" factory-method="mock"> + <bean id="accountService" class="org.mockito.Mockito" factory-method="mock"> <constructor-arg value="org.example.AccountService"/> </bean> @@ -2667,45 +3126,42 @@ public class AccountTests { additional builder-style methods corresponding to properties of MockHttpServletRequest. For example: - -mockMvc.perform(post("/hotels/{id}", 42).accept(MediaType.APPLICATION_JSON)); + mockMvc.perform(post("/hotels/{id}", 42).accept(MediaType.APPLICATION_JSON)); In addition to all the HTTP methods, you can also perform file upload requests, which internally creates an instance of MockMultipartHttpServletRequest: - -mockMvc.perform(fileUpload("/doc").file("a1", "ABC".getBytes("UTF-8"))); + mockMvc.perform(fileUpload("/doc").file("a1", "ABC".getBytes("UTF-8"))); Query string parameters can be specified in the URI template: - -mockMvc.perform(get("/hotels?foo={foo}", "bar")); + mockMvc.perform(get("/hotels?foo={foo}", "bar")); Or by adding Servlet request parameters: - -mockMvc.perform(get("/hotels").param("foo", "bar")); + mockMvc.perform(get("/hotels").param("foo", "bar")); If application code relies on Servlet request parameters, and doesn't check the query string, as is most often the case, then it doesn't matter how parameters are added. Keep in mind though that parameters provided in the URI template will be decoded while - parameters provided through the param(...) method are - expected to be decoded. + parameters provided through the param(...) + method are expected to be decoded. In most cases it's preferable to leave out the context path - and the servlet path from the request URI. If you must test with the - full request URI, be sure to set the contextPath and servletPath - accordingly so that request mappings will work: + and the Servlet path from the request URI. If you must test with the + full request URI, be sure to set the + contextPath and + servletPath accordingly so that request + mappings will work: - -mockMvc.perform(get("/app/main/hotels/{id}").contextPath("/app").servletPath("/main")) + mockMvc.perform(get("/app/main/hotels/{id}").contextPath("/app").servletPath("/main")) Looking at the above example, it would be cumbersome to set @@ -2713,8 +3169,7 @@ mockMvc.perform(get("/app/main/hotels/{id}").contextPath("/app").servletPath("/m why you can define default request properties when building the MockMvc: - -public class MyWebTests { + public class MyWebTests { private MockMvc mockMvc; @@ -2740,14 +3195,13 @@ public class MyWebTests { Defining Expectations Expectations can be defined by appending one or more - .andExpect(..) after call to perform the + .andExpect(..) after call to perform the request: - -mockMvc.perform(get("/accounts/1")).andExpect(status().isOk()); + mockMvc.perform(get("/accounts/1")).andExpect(status().isOk()); - MockMvcResultMatchers.* defines a number of + MockMvcResultMatchers.* defines a number of static members, some of which return types with additional methods, for asserting the result of the performed request. The assertions fall in two general categories. @@ -2772,41 +3226,35 @@ mockMvc.perform(post("/persons")) Many times when writing tests, it's useful to dump the result - of the performed request. This can be done as follows: + of the performed request. This can be done as follows, where + print() is a static import from + MockMvcResultHandlers: - -mockMvc.perform(post("/persons")) + mockMvc.perform(post("/persons")) .andDo(print()) .andExpect(status().isOk()) - .andExpect(model().attributeHasErrors("person")); - + .andExpect(model().attributeHasErrors("person")); - where print() is a static import from - MockMvcResultHandlers. As long as request processing - does cause an unhandled exception, the print() method - will print all the available result data to - System.out. + As long as request processing causes an unhandled exception, + the print() method will print all the available + result data to System.out. In some cases, you may want to get direct access to the result and verify something that cannot be verified otherwise. This can be - done by appending .andReturn() at the end after all - expectations: + done by appending .andReturn() at the end after + all expectations: - -MvcResult mvcResult = mockMvc.perform(post("/persons")).andExpect(status().isOk()).andReturn(); -// ... - + MvcResult mvcResult = mockMvc.perform(post("/persons")).andExpect(status().isOk()).andReturn(); +// ... When all tests repeat the same expectations, you can define the common expectations once when building the MockMvc: - -standaloneSetup(new SimpleController()) + standaloneSetup(new SimpleController()) .alwaysExpect(status().isOk()) .alwaysExpect(content().contentType("application/json;charset=UTF-8")) - .build() - + .build() Note that the expectation is always applied and cannot be overridden without creating a separate @@ -2817,21 +3265,17 @@ standaloneSetup(new SimpleController()) xl:href="https://github.com/SpringSource/spring-hateoas">Spring HATEOAS, the resulting links can be verified: - -mockMvc.perform(get("/people").accept(MediaType.APPLICATION_JSON)) - .andExpect(jsonPath("$.links[?(@.rel == 'self')].href").value("http://localhost:8080/people")); - + mockMvc.perform(get("/people").accept(MediaType.APPLICATION_JSON)) + .andExpect(jsonPath("$.links[?(@.rel == 'self')].href").value("http://localhost:8080/people")); When XML response content contains hypermedia links created with Spring HATEOAS, the resulting links can be verified: - -Map<String, String> ns = Collections.singletonMap("ns", "http://www.w3.org/2005/Atom"); + Map<String, String> ns = Collections.singletonMap("ns", "http://www.w3.org/2005/Atom"); mockMvc.perform(get("/handle").accept(MediaType.APPLICATION_XML)) - .andExpect(xpath("/person/ns:link[@rel='self']/@href", ns).string("http://localhost:8080/people")); - + .andExpect(xpath("/person/ns:link[@rel='self']/@href", ns).string("http://localhost:8080/people"));
@@ -2841,9 +3285,7 @@ mockMvc.perform(get("/handle").accept(MediaType.APPLICATION_XML)) register one or more Filter instances: - -mockMvc = standaloneSetup(new PersonController()).addFilters(new CharacterEncodingFilter()).build(); - + mockMvc = standaloneSetup(new PersonController()).addFilters(new CharacterEncodingFilter()).build(); Registered filters will be invoked through MockFilterChain from @@ -2870,16 +3312,14 @@ mockMvc = standaloneSetup(new PersonController()).addFilters(new CharacterEncodi RestTemplate. The goal is to define expected requests and provide "stub" responses: - -RestTemplate restTemplate = new RestTemplate(); + RestTemplate restTemplate = new RestTemplate(); MockRestServiceServer mockServer = MockRestServiceServer.createServer(restTemplate); mockServer.expect(requestTo("/greeting")).andRespond(withSuccess("Hello world", "text/plain")); // use RestTemplate ... -mockServer.verify(); - +mockServer.verify(); In the above example, MockRestServiceServer -- the central class for @@ -2893,8 +3333,9 @@ mockServer.verify(); Once expected requests and stub responses have been defined, the RestTemplate can be used in client-side code as - usual. At the end of the tests mockServer.verify() can be - used to verify that all expected requests were performed. + usual. At the end of the tests mockServer.verify() + can be used to verify that all expected requests were + performed.
Static Imports