testRunFinished not run in JUnit integration

Old Forum Archive Bugs
1

Hi I am developing an application using Arquillian. Arquillian relaies on JUnit listeners to launch some internal events. One of the last events that are thrown inside Arquillian is AfterSuite event. This Arquillian event might be responsible to clean up some elements that could be created during the test phase (for example a Docker container). This event is called when testRunFinished method from JUnit RunListener is called (https://github.com/junit-team/junit/blob/3e43555e1f4df95b0a239f453af6d3226a8fef6e/src/main/java/org/junit/runner/notification/SynchronizedRunListener.java#L42)

So I written my test I run my test in IntelliJ and everything works and AfterSuite event is called and everything is cleaned, then I run in Eclipse and it works the same, then I run on Maven (oh yes sorry) and it works the same, but then I use Gradle and surprise, the AfterSuite event is not called so my environment is not cleaned.

I have inspect the logs of Arquillian in trace mode (where you can see all the events that are thrown), and I can see that all the events are thrown (for example BeforeSuite, BeforeTest, …) but the AfterSuite is not called ever. Since it is called when using Maven, Eclipse, IntelliJ, I suspect that this is a problem on Gradle JUnit integration (probably not calling the testRunFinished method).

Is this possible?

I am using Gradle 2.10 and Java 8 and JUnit 4.12

1 Like
2

Hey Alex,

I can confirm that gradle does not fire this event. In the gradle test execution infrastructure a org.junit.runner.notification.RunNotifier is just passed to a org.junit.runner.Runner instance. The RunNotifier does not call the fireTestRunFinished. Maven worked around this by wrapping the Default RunNotifier class and calling this explicitly from the maven codebase. One difference from comparing the surefire and the gradle codebase briefly is, that Gradle instantiates a Runner per Class where surefire does not strictly do this. I created GRADLE-3411 for this to track further disussions around this.

On further thing to note here is, that in the junit codebase actually there is a comment about you should not invoke this method at all as it is likely to be moved.