Registration hook in JUnit to notify test finished

[Malte Finsterwalder-2]

Hi,

is there a way to get notified when the last test was run and JUnit is finished?
Could I register a "shutdown-hook" of some sort?
I would like to clean up a shared resource after my tests are run.
Initializing it lazily works fine, but how do I get rid of it?

Or is there another way I can use?

Greetings,
   Malte

[kentb]

We don't have a simple way to do what you want to do. If you're building the
suite yourself, you should be able to put an @After on the suite class in
which you can clean up.
 
The philosophy in JUnit has always been for tests to be self-contained, each
leaving the world exactly as they found it. Such tests are more valuable and
less expensive than tests with hysteresis. On the other hand, it can be a
challenge to figure out how to design the system so that such tests are
possible or provide sufficient confidence.
 
Regards,
 
Kent

  _____  

From: junit@... [mailto:junit@...] On Behalf Of
Malte Finsterwalder
Sent: Thursday, October 22, 2009 8:17 AM
To: junit YahooGroup
Subject: [junit] Registration hook in JUnit to notify test finished


 

Hi,

is there a way to get notified when the last test was run and JUnit is
finished?
Could I register a "shutdown-hook" of some sort?
I would like to clean up a shared resource after my tests are run.
Initializing it lazily works fine, but how do I get rid of it?

Or is there another way I can use?

Greetings,
Malte





[Non-text portions of this message have been removed]

[Malte Finsterwalder-2]

Hi Kent,

kentb wrote:
> We don't have a simple way to do what you want to do. If you're building the
> suite yourself, you should be able to put an @After on the suite class in
> which you can clean up.
>  
> The philosophy in JUnit has always been for tests to be self-contained, each
> leaving the world exactly as they found it. Such tests are more valuable and
> less expensive than tests with hysteresis. On the other hand, it can be a
> challenge to figure out how to design the system so that such tests are
> possible or provide sufficient confidence.

I know. But my canonical Example is Tests that need a database. I know
that testing with a database is not the best idea, but some tests
obviously need it. I could open a connection for every testclass in
@BeforeClass and close it in @AfterClass. But I don't see a problem with
reusing the connection for several testclasses. But I do want to clean
up at the end.
I don't use TestSuites and I would like the feature to work regardless
of whether I run the tests solo or in groups or all my tests together.

Greetings,
   Malte

[David Saff]

Malte,

If you could design the syntax for this feature request, what would it
look like?

   David Saff

On Thu, Oct 22, 2009 at 3:10 PM, Malte Finsterwalder
<malte@...> wrote:

> Hi Kent,
>
> kentb wrote:
>> We don't have a simple way to do what you want to do. If you're building the
>> suite yourself, you should be able to put an @After on the suite class in
>> which you can clean up.
>>
>> The philosophy in JUnit has always been for tests to be self-contained, each
>> leaving the world exactly as they found it. Such tests are more valuable and
>> less expensive than tests with hysteresis. On the other hand, it can be a
>> challenge to figure out how to design the system so that such tests are
>> possible or provide sufficient confidence.
>
> I know. But my canonical Example is Tests that need a database. I know
> that testing with a database is not the best idea, but some tests
> obviously need it. I could open a connection for every testclass in
> @BeforeClass and close it in @AfterClass. But I don't see a problem with
> reusing the connection for several testclasses. But I do want to clean
> up at the end.
> I don't use TestSuites and I would like the feature to work regardless
> of whether I run the tests solo or in groups or all my tests together.
>
> Greetings,
>   Malte
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Malte Finsterwalder-2]

Hello David,

2009/10/23 David Saff <david@...>:
> If you could design the syntax for this feature request, what would it
> look like?

Either a more traditional way with calling an API:

getApi().registerJUnitEventListener(new EventListener() {
....
});

Or easier with an annotation:

@JUnitShutdown
public static void shutdownMethod() {
...
}

JUnit would then register this method for execution after finishing
the last test run.

And maybe even:

@JUnitStartup
public static void startupMethod() {
...
}

This would require that JUnit scans all the TestCases before launching
any one of them, though.
I think this is less important, since I can easily mimic it with @BeforeClass.

I didn't think much about the specific naming. Just to give an idea.
BTW: TestNG has an @AfterSuite-Annotation, that is supposed to do just that.

What do you think?

Greetings,
   Malte

[Alistair Israel]

Hi, David, Malte.

May I barge in?

I'm seeing myself, and others needing what could be called 'lifecycle'
event listeners/hooks in JUnit:
 - JUnit startup/shutdown
 - before/after suite
 - before/after class
 - before/after method

We have the last two, but not the others. Other things we might be
interested in are test successes, failures and exceptions (currently
available using the TestWatchman Rule).

How about calling them "join points", being able to describe/group
them using "point cuts" then specifying the associated code to be
executed, or the "advice"?

We could even have 'around' advice, which would be equivalent to
MethodRules. Advice 'around' test class would be class rules, and so
on.

I realize the added complexity (not to mention the unfamiliar
nomenclature) might be controversial, so I've been hesitating to
suggest this.

- alistair
--
http://alistairisrael.wordpress.com

[Bogdan Mocanu-3]

Hi guys,

I vote in favor of this idea.

As you said, these pieces of advice could get, as a parameter,
a Report object, from where you can find out how many tests
have been executed, which and how many of them failed/succeeded/were
ignored, which is the next test to execute, etc.

We could have a @Listener annotation, which accepts a class as a
parameter.
The class could have 2 methods, before() and after() (we could also make
it
optional to have the around() method, just like AOP advices).

If you annotate a TestSuite, then you are basically listening to JUnit
start/stop
events. If you annotate a test, then it is beforeClass and afterClass.
And finally,
if you annotate a method, then you are listening before/after that test
class.

Regards,
Bogdan

--- In junit@..., Alistair Israel <aisrael@...> wrote:

>
> Hi, David, Malte.
>
> May I barge in?
>
> I'm seeing myself, and others needing what could be called 'lifecycle'
> event listeners/hooks in JUnit:
>  - JUnit startup/shutdown
>  - before/after suite
>  - before/after class
>  - before/after method
>
> We have the last two, but not the others. Other things we might be
> interested in are test successes, failures and exceptions (currently
> available using the TestWatchman Rule).
>
> How about calling them "join points", being able to describe/group
> them using "point cuts" then specifying the associated code to be
> executed, or the "advice"?
>
> We could even have 'around' advice, which would be equivalent to
> MethodRules. Advice 'around' test class would be class rules, and so
> on.
>
> I realize the added complexity (not to mention the unfamiliar
> nomenclature) might be controversial, so I've been hesitating to
> suggest this.
>
> - alistair
> --
> http://alistairisrael.wordpress.com
>

[Clive Evans]

On 23 Oct 2009, at 12:30, Alistair Israel wrote:

> Hi, David, Malte.
>
> May I barge in?
>
> I'm seeing myself, and others needing what could be called 'lifecycle'
> event listeners/hooks in JUnit:
> - JUnit startup/shutdown
> - before/after suite
> - before/after class
> - before/after method
>
> We have the last two, but not the others. Other things we might be
> interested in are test successes, failures and exceptions (currently
> available using the TestWatchman Rule).

Actually, you do have before/after suite, by using @BeforeClass and  
@AfterClass in the suite class.

We're currently doing this to set up and tear down resources that are  
slow to create but needed by every test in our functional test suite.  
It works ok, but does mean that the tests have to be run as part of  
the suite (or modified), which is inconvenient.

If it starts to annoy me enough, I'll be switching to writing our own  
test runner, but it would be nice if there was a simple way to set up  
a shared resource before running any of a set of arbitrarily selected  
tests.

Clive

[Daniel Brolund-2]

Hi,

I'm also in favor of this idea.

I would like to add a "feature detail request": It would be nice to be able
to propagate "advices-pointcuts"/rules throughout a suite (incl subsuites,
tests and test methods) to be able to avoid configuration duplication.

I made an implementation of such rules (not quite AOP-style ,but
Rule-style). Please see
http://github.com/brolund/junit
for code details.

I had to make minor structural changes to be able to pass a "context" to the
sub-suites.

Cheers
Daniel








On Fri, Oct 23, 2009 at 1:30 PM, Alistair Israel <aisrael@...> wrote:

>
>
> Hi, David, Malte.
>
> May I barge in?
>
> I'm seeing myself, and others needing what could be called 'lifecycle'
> event listeners/hooks in JUnit:
> - JUnit startup/shutdown
> - before/after suite
> - before/after class
> - before/after method
>
> We have the last two, but not the others. Other things we might be
> interested in are test successes, failures and exceptions (currently
> available using the TestWatchman Rule).
>
> How about calling them "join points", being able to describe/group
> them using "point cuts" then specifying the associated code to be
> executed, or the "advice"?
>
> We could even have 'around' advice, which would be equivalent to
> MethodRules. Advice 'around' test class would be class rules, and so
> on.
>
> I realize the added complexity (not to mention the unfamiliar
> nomenclature) might be controversial, so I've been hesitating to
> suggest this.
>
> - alistair
> --
> http://alistairisrael.wordpress.com
>  
>

--
---------------------------------------------------------
Daniel Brolund
Agical AB - www.agical.com

work: daniel.brolund@...
phone: [phone]
blog:http://danielbrolund.wordpress.com
twitter: @danielbrolund
private: daniel.brolund@...


[Non-text portions of this message have been removed]

[David Saff]

Malte,

For your specific case, could you use Runtime.addShutdownHook()?

   David Saff

On Fri, Oct 23, 2009 at 2:46 AM, Malte Finsterwalder
<malte@...> wrote:

> Hello David,
>
> 2009/10/23 David Saff <david@...>:
>> If you could design the syntax for this feature request, what would it
>> look like?
>
> Either a more traditional way with calling an API:
>
> getApi().registerJUnitEventListener(new EventListener() {
> ....
> });
>
> Or easier with an annotation:
>
> @JUnitShutdown
> public static void shutdownMethod() {
> ...
> }
>
> JUnit would then register this method for execution after finishing
> the last test run.
>
> And maybe even:
>
> @JUnitStartup
> public static void startupMethod() {
> ...
> }
>
> This would require that JUnit scans all the TestCases before launching
> any one of them, though.
> I think this is less important, since I can easily mimic it with @BeforeClass.
>
> I didn't think much about the specific naming. Just to give an idea.
> BTW: TestNG has an @AfterSuite-Annotation, that is supposed to do just that.
>
> What do you think?
>
> Greetings,
>   Malte
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Malte Finsterwalder-2]

2009/10/23 David Saff <david@...>:
> For your specific case, could you use Runtime.addShutdownHook()?

Just tried it and it seams to be called, at least in Eclipse.
I'm not sure what the JVM guarantees, when it comes to shutdownHooks.
I think I remember that they are not guaranteed to run and the might
be aborted in mid run, I think.

In general I don't think this is a good idea. I can imagine cases,
were it doesn't work, like in an ant-build that doesn't fork for
junit.

So I still think a lifecycle hook in JUnit would be the "right" solution.

Greetings,
   Malte

[Forsberg, Mike-2]

I think shutdown hooks are ran and a guaranteed to run unless a
Runtime.halt is called.  This is for Java 1.6

 

A shutdown hook is simply an initialized but unstarted thread. When the
virtual machine begins its shutdown sequence it will start all
registered shutdown hooks in some unspecified order and let them run
concurrently. When all the hooks have finished it will then run all
uninvoked finalizers if finalization-on-exit has been enabled. Finally,
the virtual machine will halt. Note that daemon threads will continue to
run during the shutdown sequence, as will non-daemon threads if shutdown
was initiated by invoking the exit
<file:///C:\Java\Java6Docs\api\java\lang\Runtime.html#exit%28int%29>
method.

 

Pulled from the API under Runtime addShutdownHook

 

Big Mike

 

From: junit@... [mailto:junit@...] On Behalf Of
Malte Finsterwalder
Sent: Friday, October 23, 2009 12:08 PM
To: junit@...
Subject: Re: [junit] Registration hook in JUnit to notify test finished

 

 

2009/10/23 David Saff <david@... <mailto:david%40saff.net> >:
> For your specific case, could you use Runtime.addShutdownHook()?

Just tried it and it seams to be called, at least in Eclipse.
I'm not sure what the JVM guarantees, when it comes to shutdownHooks.
I think I remember that they are not guaranteed to run and the might
be aborted in mid run, I think.

In general I don't think this is a good idea. I can imagine cases,
were it doesn't work, like in an ant-build that doesn't fork for
junit.

So I still think a lifecycle hook in JUnit would be the "right"
solution.

Greetings,
Malte





[Non-text portions of this message have been removed]

[David Saff]

On Fri, Oct 23, 2009 at 1:08 PM, Malte Finsterwalder
<malte@...> wrote:

> 2009/10/23 David Saff <david@...>:
>> For your specific case, could you use Runtime.addShutdownHook()?
>
> Just tried it and it seams to be called, at least in Eclipse.
> I'm not sure what the JVM guarantees, when it comes to shutdownHooks.
> I think I remember that they are not guaranteed to run and the might
> be aborted in mid run, I think.
>
> In general I don't think this is a good idea. I can imagine cases,
> were it doesn't work, like in an ant-build that doesn't fork for
> junit.

I agree.  But from a feature prioritization point of view, it helps to
know that addShutdownHook will work for you, and something more
complicated would help a smaller set of people, who use ant without
forking and need shutdown behavior.

   David Saff

>
> So I still think a lifecycle hook in JUnit would be the "right" solution.
>
> Greetings,
>   Malte
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>