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: - Eclipse makes no distinction between compile and test classpaths. If we do this the tests will run with different class paths in the IDE and on the command line. - I'm not sure it's possible in Maven. @snicoll?
Comment From: snicoll
Not possible in Maven AFAIK. The closest would be a (maven) profile that's only enabled when you run your app
Comment From: snicoll
At this point, disabling devtools when it's running in a test environment would be the easiest. Thoughts @philwebb ?
Comment From: philwebb
Let's try and do this in the code since Eclipse and Maven will require that solution anyway.
Comment From: snicoll
And IntelliJ IDEA and Netbeans.
Comment From: philwebb
@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?
Comment From: wilkinsona
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.
Comment From: snicoll
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?
Comment From: jkuipers
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.
Comment From: natix643
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.
Comment From: nayeemzen
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.
Comment From: philwebb
See #15277 for an example of the issue this can cause
Comment From: wilkinsona
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.
Comment From: tonyschwartz
Why in the world was this behavior changed? What is the recommended work-around? I do not agree with the reasoning behind this change. It is perfectly sane to use this standard mechanism to inject properties into your integration tests.
Comment From: wilkinsona
Reading between the lines a little, I guess you were using DevTools' global settings support to set properties in your integration tests. As a replacement, I would use a profile-specific application.properties or application.yaml file and activate that profile active when running your integration tests.
Comment From: tonyschwartz
The beauty of using the .spring-boot-devtools.properties on a developer's box is that sensitive credentials can be tucked away and encrypted. Using profile-specific application.properties is dangerous as developers tend to space what's going on and you end up with credentials checked into your repo.
Comment From: scottfrederick
You can achieve this by importing the file directly as optional, like spring.config.import=optional:file:.spring-boot-devtools.properties. Some users store these types of values in environment variables and import them into the environment as described in this StackOverflow question.
Comment From: tonyschwartz
This comes with issues too, and isn't much different in the end. For example, where is the optional file located on any given user's development box? I just don't understand the logic in removing this devtools behavior which is perfectly sane and useful.
Comment From: philwebb
@tonyschwartz I think we need to take a step back here. This issue is 7 years old and whilst you may not agree with reasoning behind the change, experience has shown us that enabling all of devtools in tests is very problematic.
It does sound like you have a valid use-case that you'd like to see addressed. Other users have also struggled with using application.properties in tests. With that in mind, I've opened #38098 to see if we can improve things.
Comment From: philwebb
Feel free to add a comment to that issue that details the functionality you'd like to see added.
Comment From: tonyschwartz
@philwebb I understand developers can abuse and things can get messy. I appreciate you acknowledging my use-case. I find the .spring-boot-devtools.properties an elegant and sane solution to my use-case, a common use-case I might add. It has bothered me that it was shut off.