GeeCON Prague 2014*
The moose likes Testing and the fly likes JUnit lifecycle listeners Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Testing
Bookmark "JUnit lifecycle listeners" Watch "JUnit lifecycle listeners" New topic
Author

JUnit lifecycle listeners

Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10146
    
165

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:



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:


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



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?

[My Blog] [JavaRanch Journal]
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1763
    
    7

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.


Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10146
    
165

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
Bartender

Joined: Mar 10, 2008
Posts: 1763
    
    7

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
Marshal

Joined: Jul 20, 2005
Posts: 10146
    
165

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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: JUnit lifecycle listeners