title: Spring Boot integration tests: @AutoConfigureMockMvc and context caching
body: <p>I'm building very basic web application using Spring Boot 1.5.1 and wanted to create integration tests for checking REST endpoints.
  As recomended by documentation, MockMvc might be used for it.</p>
  
  <p>Here is very simple test class:</p>
  
  <pre><code>package foo.bar.first;
  
  import ...
  
  @RunWith(SpringRunner.class)
  @SpringBootTest
  @AutoConfigureMockMvc
  public class ApplicationTest1 {
  
      @Autowired
      private WebApplicationContext context;
  
      @Autowired
      private MockMvc mvc;
  
      @Test
      public void shouldStartWebApplicationContext() {
          assertThat(context).isNotNull();
      }
  
      @Test
      public void shouldReplyToPing() throws Exception {
          mvc.perform(get("/ping"))
                  .andExpect(status().isOk());
      }
  }
  </code></pre>
  
  <p>As expected, it starts full application context and runs tests. </p>
  
  <p>Later I have created other similar test classes and noticed that brand <strong>new application context</strong> is started up for <strong>each test class</strong>. Experiments show that context is shared only between test classes from same package.</p>
  
  <p>For example, if same test class copied multiple times, then contexts are as follows:</p>
  
  <pre><code>foo.bar
    first
      ApplicationTest1 (shared context)
      ApplicationTest2 (shared context)
    second
      ApplicationTest3 (brand new context)
  </code></pre>
  
  <p>Also further investigations showed that it is related to <code>@AutoConfigureMockMvc</code> annotation. If the annotation and MockMvc related test cases are removed, then all three classes sucessfully <strong>share the same context</strong>.</p>
  
  <p>So the question is how to get <strong>shared context for all tests with MockMvc</strong>?</p>
  
  <p>Note: other resources suggest to use <code>MockMvcBuilders.webAppContextSetup(context).build()</code> for getting MockMvc instance, but it does not work for me (it does not involve filters when processing web requests).</p>