anchor.diff:  	mockMvc = standaloneSetup(new PersonController()).addFilters(new CharacterEncodingFilter()).build();
   ----
   
  -Registered filters will be invoked through `MockFilterChain` from `spring-test` and the
  -last filter will delegates to the `DispatcherServlet`.
  +Registered filters will be invoked through via the `MockFilterChain` from `spring-test`, and the
  +last filter will delegate to the `DispatcherServlet`.
   
   [[spring-mvc-test-vs-end-to-end-integration-tests]]
  -===== Difference With End-to-End Integration Tests
  +===== Differences between Out-of-Container and End-to-End Integration Tests
   
   As mentioned earlier __Spring MVC Test__ is built on the Servlet API mock objects from
  -the `spring-test` module and does not rely on a running Servlet container. Therefore
  +the `spring-test` module and does not use a running Servlet container. Therefore
   there are some important differences compared to full end-to-end integration tests
   with an actual client and server running.
   
   The easiest way to think about this is starting with a blank `MockHttpServletRequest`.
  -Whatever you add to it is what the request will be. The things that may catch you out are
  -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 be asserted with expectations.
  +Whatever you add to it is what the request will be. 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 be asserted with
  +expectations.
   
   This means if you are using JSPs you can verify the JSP page to which the request was
  -forwarded but there won't be any HTML rendered. Note however that all other rendering
  -technologies that don't rely on forwarding such as Thymeleaf, Freemarker, Velocity
  -will render HTML to the response body as expected. The same is true for rendering JSON,
  -XML and others via `@ResponseBody` methods.
  +forwarded, but there won't be any HTML rendered. In other words, the JSP will not be
  +_invoked_. Note however that all other rendering technologies which don't rely on
  +forwarding such as Thymeleaf, Freemarker, and Velocity will render HTML to the response
  +body as expected. The same is true for rendering JSON, XML, and other formats via
  +`@ResponseBody` methods.
   
   Alternatively you may consider the full end-to-end integration testing support from
   Spring Boot via `@WebIntegrationTest`. See the
   http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-testing.html#boot-features-testing-spring-boot-applications[Spring Boot reference].
   
  -There are pros and cons for each. The options provided in __Spring MVC Test__
  -are different stops on the scale from classic unit to full integration tests.
  -To be sure none of the options in Spring MVC Test are classic unit tests but they are a
  -little closer to it. For example you can isolate the service layer with mocks
  -injected into controllers and then you're testing the web layer only through
  -the `DispatcherServlet` and with actual Spring configuration, just like you might test
  -the database layer in isolation of the layers above. Or you could be using the
  -standalone setup focusing on one controller at a time and manually providing the
  -configuration required to make it work.
  +There are pros and cons for each approach. The options provided in __Spring MVC Test__
  +are different stops on the scale from classic unit testing to full integration testing.
  +To be certain, none of the options in Spring MVC Test fall under the category of classic
  +unit testing, but they _are_ a little closer to it. For example, you can isolate the web
  +layer by injecting mocked services into controllers, in which case you're testing the web
  +layer only through the `DispatcherServlet` but with actual Spring configuration, just
  +like you might test the data access layer in isolation from the layers above. Or you
  +can use 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 on the inside of the server-side so you can check what handler was used,
  +tests are on the _inside_ of 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 errors there were, etc. That means it's easier to write
   expectations since the server is not a black box as it is when testing it through
  -an actual HTTP client. This is generally the advantage of classic unit testing that it's
  +an actual HTTP client. This is generally an advantage of classic unit testing, that it's
   easier to write, reason about, and debug but does not replace the need for full
  -integration tests. At the same time it's important not to lose sight of the fact
  -the response is the most important thing to check. In short there is room here for
  -multiple styles and strategies of testing even in the same project.
  +integration tests. At the same time it's 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 of testing even within the same project.
   
   
   [[spring-mvc-test-server-resources]]
  
positive.code: ----
  
  The above test relies on the `WebApplicationContext` support of the __TestContext framework__
  to loads Spring configuration from an XML configuration file located in the same package
  as the test class but also supported is Java-based configuration. See these
  https://github.com/spring-projects/spring-framework/tree/master/spring-test/src/test/java/org/springframework/test/web/servlet/samples/context[sample tests].
  
  The `MockMvc` instance is used to perform a request to `"/accounts/1"` and verify the
  resulting response has status 200, content type is `"application/json"`, and
  response body has a JSON property called "name" with the value "Lee". The jsonPath
  syntax is supported  through the Jayway https://github.com/jayway/JsonPath[JsonPath
  project]. There are lots of other options for verifying the result of the performed
  request that will be discussed below.
  
  
negative.code: 		.build()
  ----
  
  Note that common expectations are __always__ applied and cannot be overridden without
  creating a separate `MockMvc` instance.
  
  When JSON response content contains hypermedia links created with
  https://github.com/spring-projects/spring-hateoas[Spring HATEOAS], the resulting links can
  be verified using JsonPath expressions:
  
  [source,java,indent=0]
  [subs="verbatim,quotes"]
  