title: Spring Context Test With Just One Bean
body: <p>What's the recommended way to run a spring boot test where only the one subject under test is configured in the context.</p>
  
  <p>If I annotate the test with </p>
  
  <pre><code>@RunWith(SpringRunner.class)
  @SpringBootTest(properties = "spring.profiles.active=test")
  @ContextConfiguration(classes = MyTestBean.class)
  </code></pre>
  
  <p>Then it seems to work - the test passes, the context starts quickly and seems to only contain the bean that I want. However, this seems like an incorrect use of the <code>@ContextConfiguration(classes = MyTestBean.class)</code> annotation. If I understand correctly the class that I reference is supposed to be a <code>Configuration</code> class, not a regular spring service bean or component for example.</p>
  
  <p>Is that right? Or is this indeed a valid way to achieve this goal? I know there are more complex examples like <code>org.springframework.boot.test.autoconfigure.json.JsonTest</code> which use <code>@TypeExcludeFilters(JsonExcludeFilter.class)</code> to control the context - but this seems overkill for my use case. I just want a context with my one bean. </p>
  
  <h2>Clarification</h2>
  
  <p>I know that I can just construct the one bean I am testing as a POJO without a spring context test and remove the three annotations above. But in my precise use case I am actually reliant on some of the configuration applied to the context by settings in the <code>application-test.properties</code> file - which is why I've made this a Spring Boot test with a profile set. From my perspective this isn't a plain unit test of a single class in isolation of the spring context configuration - the test is reliant on certain configuration being applied (which is currently provided by the spring boot app properties). I can indeed just test the components as a POJO by creating a new instance outside of a spring context, I'm using constructor injection making the providing of necessary dependencies simple but the test does rely on things like the log level (the test actually makes assertions on certain logs being produced) which requires that the log level is set correctly (which is currently being done via <code>logging.level.com.example=DEBUG</code> in a properties file which sets up the spring context).</p>