anchor.diff:  [[spring-mvc-test-server-htmlunit-why-integration]]
   ====== Integration Testing to the Rescue?
   
  -To resolve the issues mentioned earler, we could perform end-to-end integration testing, but this has
  -some drawbacks. Consider testing the view that lets us page through the messages.
  -We might need the following tests:
  -
  -* Does our page display a notification to the user to indicate that no results are available
  -when the messages are empty?
  +To resolve the issues mentioned earlier, we could perform end-to-end integration testing,
  +but this has some drawbacks. Consider testing the view that lets us page through the
  +messages. We might need the following tests:
  +
  +* Does our page display a notification to the user to indicate that no results are
  +  available when the messages are empty?
   * Does our page properly display a single message?
   * Does our page properly support paging?
   
  -To set up these tests, we need to ensure our database contains the proper messages.
  -This leads to a number of additional challenges:
  +To set up these tests, we need to ensure our database contains the proper messages. This
  +leads to a number of additional challenges:
   
   * Ensuring the proper messages are in the database can be tedious. (Consider foreign key
     constraints.)
  -* Testing can become slow, since each test would need to ensure that the database is in the
  -  correct state.
  +* Testing can become slow, since each test would need to ensure that the database is in
  +  the correct state.
   * Since our database needs to be in a specific state, we cannot run tests in parallel.
  -* Performing assertions on such items as auto-generated ids, timestamps, and others can be difficult.
  +* Performing assertions on such items as auto-generated ids, timestamps, and others can
  +  be difficult.
   
   These challenges do not mean that we should abandon end-to-end integration testing
   altogether. Instead, we can reduce the number of end-to-end integration tests by
  -refactoring our detailed tests to use mock services that run much faster, more
  -reliably, and without side effects. We can then implement a small number of true
  -end-to-end integration tests that validate simple workflows to ensure that everything
  -works together properly.
  +refactoring our detailed tests to use mock services that run much faster, more reliably,
  +and without side effects. We can then implement a small number of true end-to-end
  +integration tests that validate simple workflows to ensure that everything works together
  +properly.
   
   
   
  
positive.code: standard semantics on any application components configured in the `ApplicationContext`.
  However, these lifecycle annotations have limited usage within an actual test class.
  
  If a method within a test class is annotated with `@PostConstruct`, that method
  runs before any before methods of the underlying test framework (for example, methods
  annotated with JUnit Jupiter's `@BeforeEach`), and that applies for every test method
  in the test class. On the other hand, if a method within a test class is annotated with
  `@PreDestroy`, that method never runs. Therefore, within a test class, we
  recommend that you use test lifecycle callbacks from the underlying test framework
  instead of `@PostConstruct` and `@PreDestroy`.
  ====
  
  
  
negative.code: 
  ===== `TestContextManager`
  
  `TestContextManager` is the main entry point into the Spring TestContext Framework and is
  responsible for managing a single `TestContext` and signaling events to each registered
  `TestExecutionListener` at well-defined test execution points:
  
  * Prior to any "`before class`" or "`before all`" methods of a particular testing framework.
  * Test instance post-processing.
  