It should be possible to run tests without starting the CommandLineRunner

[berlin-ab]

We are trying to do integration testing by loading the Spring Boot environment, injecting some dependencies into our test classes via @Autowired, etc. We're running into issues where our tests are competing with the CommandLineRunner that starts when the SB environment loads.

[philwebb]

Could you use profiles to exclude the CommandLineRunner beans from your tests?

[berlin-ab]

Is it possible to say @NotProfile("test")?

[philwebb]

You can use ! as a prefix. e.g. @Profile("!test"). See https://jira.spring.io/browse/SPR-8728 for background.

[berlin-ab]

@philwebb What does Spring Boot do for the embedded tomcat instance when running integration tests?

[philwebb]

@berlin-ab It can start it up fully if needed. Our internal integration tests also set server.port to 0 so it runs on a random port.

See https://github.com/spring-projects/spring-boot/blob/master/spring-boot-samples/spring-boot-sample-tomcat/src/test/java/sample/tomcat/SampleTomcatApplicationTests.java

[berlin-ab]

@philwebb I thought there was something about it not starting the container if MockMVC is in use.

[snicoll]

You need to add @WebAppConfiguration. Look at the example that Phil gave.

[berlin-ab]

@snicoll @philwebb When I'm not running a web application, I'd like to have the same behavior for a command line application.

[dsyer]

What's the "same behaviour"? The same as what? What did you mean by "competing" in the original question? Does the CommandLineRunner do something in a background thread?

[berlin-ab]

@dsyer yes, we start up a new thread.

[dsyer]

I'd have to see the code to really understand why you did that. If the app depends on something happening in that thread, then there's a race condition at runtime whether it's a test or a production environment, right? So I would expect you'd have to deal with that somehow in any case.

[berlin-ab]

No, we would not have this race condition in Production.

Here's what we have:
CommandLineRunner -> Thing -> Thread -> RepeatedTask

We want to be able to test the RepeatedTask, but we use:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes=Application.class)

so we can inject @components into RepeatedTask, which causes the CommandLineRunner to start and creates a race condition between CommandLineRunner -> Thing -> Thread -> RepeatedTask
) vs RepeatedTask.

[dsyer]

Why not create a standalone ApplicationContext that just creates a RepeatedTask and all its dependencies, and just test that then?