When it fails, the failure looks like this:
Expecting:
<"/tmp/junit4663653809537956870/test.log.%d{yyyy-MM-dd}.%i.gz">
to end with:
<"spring.log.%d{yyyy-MM-dd}.%i.gz">
For this to happen, it looks like something must have configured the LOG_FILE
system property to be a file named test.log
with a JUnit-created temporary directory. I suspect that this is due to pollution of the JVM's system properties by LoggingApplicationListenerIntegrationTests
.
If LogbackConfigurationTests
runs before LoggingApplicationListenerIntegrationTests
, defaultRollingFileNamePattern()
will pass. If they tests are run in the reverse order, defaultRollingFileNamePattern()
will fail. My suspicion is that the test becomes flaky due to Gradle's use of worker JVMs for test execution. When all of the project's tests are first executed, LoggingApplicationListenerIntegrationTests
goes first and causes LogbackConfigurationTests.defaultRollingFileNamePattern()
to fail. The test retry plugin then retries defaultRollingFileNamePattern()
and my guess is that it's run on a different worker JVM that has not had its system properties polluted. As a result, the test passes.