• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • paul wheaton
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
  • Himai Minh
Bartenders:

JUnit lifecycle listeners

 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic