anchor.diff:  [[spring-mvc-test-framework]]
   === Spring MVC Test Framework
   
  -.Standalone project
  -****
  -Before inclusion in Spring Framework 3.2, the Spring MVC Test framework had already
  -existed as a separate project on GitHub where it grew and evolved through actual use,
  -feedback, and the contribution of many.
  -
  -The standalone https://github.com/spring-projects/spring-test-mvc[spring-test-mvc project]
  -is still available on GitHub and can be used in conjunction with Spring Framework 3.1.x.
  -Applications upgrading to 3.2 or later should replace the `spring-test-mvc` dependency with a
  -dependency on `spring-test`.
  -
  -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. asynchronous web requests). The other relates to the options for creating a
  -`MockMvc` instance. In Spring Framework 3.2 and later, this can only be done through the
  -TestContext framework, which provides caching benefits for the loaded configuration.
  -****
  -
  -The __Spring MVC Test framework__ provides first class JUnit support for testing client
  -and server-side Spring MVC code 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 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.
  +The __Spring MVC Test framework__ provides first class JUnit support for testing
  +Spring MVC code using a fluent API. It's built on the
  +http://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/mock/web/package-summary.html[Servlet API mock objects]
  +from the `spring-test` module and hence does not require a running Servlet container,
  +it uses the `DispatcherServlet` thus providing full Spring MVC support, and
  +may optionally load actual Spring configuration with the __TestContext framework__
  +in addition to a standalone mode in which controllers may be instantiated manually
  +and tested one at a time.
  +
  +__Spring MVC Test__ also provides client-side support for testing code that uses
  +the `RestTemplate`. Client-side tests mock the server responses and also do not
  +require a running server.
  +
   
   
   [[spring-mvc-test-server]]
   ==== Server-Side Tests
  -Before Spring Framework 3.2, the most likely way to test a Spring MVC controller was to
  -write a unit test that instantiates the controller, injects it with mock or stub
  -dependencies, and then calls its methods directly, using a `MockHttpServletRequest` and
  -`MockHttpServletResponse` where necessary.
  -
  -Although this is pretty easy to do, controllers have many annotations, and much remains
  -untested. Request mappings, data binding, type conversion, and validation are just a few
  -examples of what isn't tested. Furthermore, there are other types of annotated methods
  -such as `@InitBinder`, `@ModelAttribute`, and `@ExceptionHandler` that get invoked as
  -part of request processing.
  -
  -The idea behind Spring MVC Test is to be able to re-write those controller tests by
  -performing actual requests and generating responses, as they would be at runtime, along
  -the way invoking controllers through the Spring MVC `DispatcherServlet`. Controllers can
  -still be injected with mock dependencies, so tests can remain focused on the web layer.
  -
  -Spring MVC Test builds on the familiar "mock" implementations of the Servlet API
  +It's easy to write a plain JUnit test for a Spring MVC controller. Simply instantiate
  +the controller, inject it with mock or stub dependencies, and call its methods
  +passing `MockHttpServletRequest`, `MockHttpServletResponse`, etc. if necessary.
  +However much remains untested, e.g. request mappings, data binding, type conversion,
  +validation and much more. Furthermore other controller methods such as `@InitBinder`,
  +`@ModelAttribute`, and `@ExceptionHandler` may also be invoked as part of the request
  +processing lifecycle.
  +
  +The goal of __Spring MVC Test__ is to provide an effective way of testing controllers
  +by performing requests and generating responses through the `DispatcherServlet`.
  +
  +__Spring MVC Test__ builds on the familiar "mock" implementations of the Servlet API
   available in the `spring-test` module. This allows performing requests and generating
   responses without the need for running in a Servlet container. For the most part
  -everything should work as it does at runtime with the exception of JSP rendering, which
  -is not available outside a Servlet container. Furthermore, if you are familiar with how
  -the `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.
  -
  -All other means of rendering including `@ResponseBody` methods and `View` types (besides
  -JSPs) such as Freemarker, Velocity, Thymeleaf, and others for rendering HTML, JSON, XML,
  -and so on should work as expected, and the response will contain the generated content.
  -
  -Below is an example of a test requesting account information in JSON format:
  +everything should work as it does at runtime with a few notable exceptions as
  +explained further below. Here is an example of using Spring MVC Test:
   
   [source,java,indent=0]
   ----
  
positive.code: 	mockMvc.perform(get("/accounts/1")).andExpect(status().isOk());
  ----
  
  `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.
  
  The first category of assertions verify properties of the response, i.e the response
  status, headers, and content. Those are the most important things to test for.
  
  The second category of assertions go beyond the response, and allow inspecting Spring
  MVC specific constructs such as which controller method processed the request, whether
  an exception was raised and handled, what the content of the model is, what view was
  selected, what flash attributes were added, and so on. It is also possible to verify
  Servlet specific constructs such as request and session attributes. The following test
  asserts that binding/validation failed:
  
  [source,java,indent=0]
  
negative.code: 	}
  ----
  
  The second is to simply create a controller instance manually without loading Spring
  configuration. Instead basic default configuration, roughly comparable to that of
  the MVC JavaConfig or the MVC namespace, is automatically created and can be customized
  to a degree:
  
  [source,java,indent=0]
  [subs="verbatim,quotes"]
  