JUnit lifecycle listeners

[Jaikiran Pai]

I have been using JUnit for a few years now. Currently i am using 4.x version of JUnit. In most of the test setups that i have worked on, JUnit is usually triggered from an Ant script, something like this:

<target name="run-my-tests">

 <!--Step1: do some setup related activities for the tests, maybe setup a server or start a server -->
 <antcall target="start-server"/>
  
 <!-- Step2: now run the tests -->
 <junit ..../>

 <!-- Step3: clean up, like stop the server --> 
 <antcall target="stop-server"/>
</target>

 

As can be seen, the test runs itself consists of 3 different steps - setup a server, run the tests and stop the server.

Personally, i would want to avoid that Ant script (or any other build script) because all it does is provide some hooks for "pre" junit start and "post" junit end lifecycles. I was wondering if there is a way i could intercept this lifecycle of JUnit from within Java.

For example i would have a JUnitLifecycleListener:

public JUnitLifecycleListener implements ? // is there some junit framework interface
{

  public void onJUnitStart()
  {
     // start my server
  }

 public void onJUnitStop()
 {
   // stop the server
  }
}

Then the testcase would point the JUnit framework to this listener (or maybe some other way):

@LifecycleListener(JUnitLifecycleListener.class)
public class SimpleTestCase 
{
  
  @Test
  public void doSomeTest()
  {
    ...
   }
}

Note that this isn't the same as relying on the @BeforeClass or @Before constructs. Instead this has to be called once during the start and stop of JUnit framework itself (irrespective of whether Ant calls it or an IDE).

Is this something possible in JUnit? Or are there other test frameworks similar to JUnit which provide this kind of hooks?

[Jelle Klap]

No such construct exists for JUnit, as far as I know. Besides, how would you propose to handle JVM forking, a feature of Ant's junit task, in such a scenario?
I'd avoid in-container testing as much as possible anyway, at least for developer test runs, and rely more on unit tests that run in isolation.
The continous integration system (buildserver) could run a more extensive set of integration / scenario tests that require a container to be up and running.
Most of those systems rely heavily on ANT scripts anyway, so I don't see the harm in having an Ant build script fire up the container in that case.

[Jaikiran Pai]

Jelle Klap wrote:
Besides, how would you propose to handle JVM forking, a feature of Ant's junit task, in such a scenario?

Forking wouldn't matter. Would it? Irrespective of whether JUnit is triggered in the same VM or a different one, the JUnit framework would go through the same lifecycle.

Jelle Klap wrote:
I'd avoid in-container testing as much as possible anyway, at least for developer test runs, and rely more on unit tests that run in isolation.

It's true that this is in-container testing and more of an integration testing that unit testing. But if the server is able to be started up in a few seconds then why not do it more frequently as part of developer test runs.

Jelle Klap wrote:
The continous integration system (buildserver) could run a more extensive set of integration / scenario tests that require a container to be up and running.
Most of those systems rely heavily on ANT scripts anyway, so I don't see the harm in having an Ant build script fire up the container in that case.

I agree that the build systems using continuous integration tools could trigger Ant scripts to do this. Infact that's how we do it now. And i don't hate Ant or such scripts, but in this specific scenario i was thinking of making this all self contained within the tests (i.e. the server startup and stop steps).

Jelle Klap wrote:
No such construct exists for JUnit, as far as I know

Jelle, thanks for confirming this. I looked through their docs and some other blogs about JUnit to see if something like this was present, but found nothing.

[Jelle Klap]

Jaikiran Pai wrote:

Jelle Klap wrote:
Besides, how would you propose to handle JVM forking, a feature of Ant's junit task, in such a scenario?

Forking wouldn't matter. Would it? Irrespective of whether JUnit is triggered in the same VM or a different one, the JUnit framework would go through the same lifecycle.

Well, if you specify that JUnit's Ant task should fork per test it will fire up a instance of the JUnit TestRunner for every test i.e. a "new instance of the JUnit framework" that has its own lifecycle, which is bound to the lifecycle of the forked JVM. Then, if you'd some how programatically manage to tie the lifecycle of the container to the lifecyle of the TestRunner, you'd be starting and stopping the container for each individual test. Unless you explicitly check if the container is already running, somehow.

[Jaikiran Pai]

Jelle Klap wrote:
Well, if you specify that JUnit's Ant task should fork per test it will fire up a instance of the JUnit TestRunner for every test i.e. a "new instance of the JUnit framework" that has its own lifecycle, which is bound to the lifecycle of the forked JVM.

Ah, yes! You are right. I hadn't thought through that scenario.