New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CitrusSpringExtension for JUnit5 does not always log the generatedReports #816
Comments
@tschlat many thanks for the detailed analysis. I think the solution with |
We were just investigating on this issue to provide a fix but it seems like this has already beenfixed in 4.0.0. This is the code of V 3.1 The current implementation calls the Citrus.afterSuite() directly in CitrusExtension.afterAll() which seems to be the right solution:
|
It is funny, because yesterday I was fixing some more issue with JUnit5 and Citrus reports. It turned out that the So I ended up using a documented workaround with closable resource to call the reporting after the suite has finished. Also I made sure to not loos test results when e.g. the Spring application context is dirty and gets reloaded. |
Here is the commit as a reference 1252851 |
I think we can call this one fixed |
Citrus Version
3.1.0
Expected behavior
Citrus logs the test execution statistics via TestReporters.generateReports at the end of a test suite execution.
Actual behavior
If Logback is for example used as an implementation for logging, the statistics are not deterministically logged. The reason for this is that this specific logging is triggered by a VM ShutDownHook which is undeterministically executed before or after the SpringApplicationShutdownHook. The later is responsible for unregistration of Logback LogAppenders. If the appenders are unregistered before the statistics logging, the log.info() call will run into no appenders and thus logging is empty.
One solution would be to add a @PreDestroy Annotation to TestReporters.generateReports to trigger the reporting. Alternatively to not mess up TestReporters with Spring specific annotations, a Bean with a @PreDestroy method could be registered dynamically within the CitrusSpringExtension which takes care of finishing.
Advice would be appreciated before I provide a fix via PR.
The text was updated successfully, but these errors were encountered: