Currently, when spring-boot-devtools is being used, it's on the classpath when a project's tests are being run using Maven or Gradle. If possible, we should exclude Dev Tools from the classpath so that the tests are run using a classpath that's as close to the application's runtime classpath as possible.
A few concerns:
Not possible in Maven AFAIK. The closest would be a (maven) profile that's only enabled when you run your app
At this point, disabling devtools when it's running in a test environment would be the easiest. Thoughts @philwebb ?
Let's try and do this in the code since Eclipse and Maven will require that solution anyway.
And IntelliJ IDEA and Netbeans.
@wilkinsona Is this specifically related to the restarer or is there some other problem? I'm just wondering what problems are being caused and where we need additional checks?
It wasn't specific to the restarter. My goal was to run the tests with a classpath and behaviour that's as close as possible to how it will be once deployed. I haven't seen any specific problems.
I am confused by this. isSkippedStackElement is supposed to disable restart if junit or the test stuff are enabled. Do you mean something else maybe?
FYI: while porting an existing application with lots of integrations tests already using an in-memory DB to Boot I ran into an issue with DevTools' DevToolsDataSourceAutoConfiguration#inMemoryDatabaseShutdownExecutor shutting down my H2 DB where that was not intended, causing me to lose my schema.
I've disabled that autoconfig during tests for now using the spring.autoconfigure.exclude property, but it would be nice if this wasn't necessary.
Hello, maybe it's obvious, but we have one use case when including devtools in tests causes problems. .spring-boot-devtools.properties have the highest possible precedence (over bundled application.properties, @TestPropertySource etc.), so if some of your unit tests depend on properties overridden in that file, your build breaks. I think that unit tests should not depend on the global environment, if possible.
I have different configurations when running tests and the application locally and wholeheartedly agree with @natix643 that unit tests should not depend on the global environment, or there should at least be an option to disable this behaviour.
See #15277 for an example of the issue this can cause
We'd like to disable everything in DevTools' spring.factories when a test is being run. That includes both environment post-processors and auto-configuration. We can use a condition for the latter and some logic similar to that in DefaultRestartInitializer for the former. It probably makes sense to pull that logic out into a utility class that can be used by the environment post-processors, restart initialiser, and condition.
Most helpful comment
Hello, maybe it's obvious, but we have one use case when including devtools in tests causes problems.
.spring-boot-devtools.propertieshave the highest possible precedence (over bundledapplication.properties,@TestPropertySourceetc.), so if some of your unit tests depend on properties overridden in that file, your build breaks. I think that unit tests should not depend on the global environment, if possible.