Comments on Mycila Blog: Writing your own JUnit extensions using @Rule

Just what I was looking for. I wanted to intercept...

2010-01-25T17:16:37.835-05:00

Just what I was looking for. I wanted to intercept the test method name and JUnit implements already this functionnality with Rule.

public class NameRuleTest {
@Rule public TestName name = new TestName();

@Test public void testA() {
assertEquals("testA", name.getMethodName());
}

@Test public void testB() {
assertEquals("testB", name.getMethodName());
}
}

Thanks. This blog entry is realy useful.

nice tone. thanks

2009-12-29T14:21:15.431-05:00

nice tone. thanks

If you debug and learn how Junit is built, perhaps...

2009-12-29T12:01:49.010-05:00

If you debug and learn how Junit is built, perhaps you'll understand much more why

if(throwable != null) throw throwable;

is required.

A Junit test method is executed as a Statement. By default, implemented as an InvokeMethod. If you put in your test @Test(expected=Foo.class), Junit wraps the InvokeMethod around an ExpectException.

So what is executed in parallel is NOT THE TEST METHOD but THE WHOLE TEST INCLUDING THE EXCEPTION ASSERTION.

What ExpectException statement does:
1. run the surrounded statement
2. if it fails, check that the expected exception is the one we got
2.1 IF YES: all is good => don't rethrow any excception since the test passed
2.2 IF NO: throw an assertion error saying that we expected Foo.class but we got anothe exception.

In your case, you run in parallel a test throwing an AssertionError, but you expect an IOException. So the Junit Statement throws an AssertionError saying this.

Since the test is run in parallel, this laster exception is trapped and rethrown by

if(throwable != null) throw throwable;

=> @Test(expecte=Foo.class) does not assert against the exception thrown by

if(throwable != null) throw throwable;

but assert against the exception thrown by the test method.

That's why

if(throwable != null) throw throwable;

is required. And if you look a little deeper with a debugger, you should see that 'throwable' has the value:

Unexpected exception, expected but was

This is the exception Junit created in the ExpectException statement, executed 10 times concurrently.

Its not that, if you remove the rethrow line but s...

2009-12-29T10:31:30.888-05:00

Its not that, if you remove the rethrow line but still throw an exception in your (now parallel) test, with an expected class for Foo but you actually throw a Bar. You get a pass, it doesn't say expected but was.

With the throw back in, its all fine. What I was getting at here is how to write a unit test to prove that the rethrow has been put in the code. At the moment it looks like a false positive.

See you amended code to demonstrate the point at http://pastie.org/760070 (surely, this test should fail?)

Junit's behavior is good: what you are running...

2009-12-28T11:18:56.279-05:00

Junit's behavior is good: what you are running in parallel is a statement, which contains the whole steps of the Junit test : execution + post-execution tests like the ExpectedException if you define one.

If you expect an exception to happen, this is logical that the test doesn't fail if this exception is really thrown.

You can test by throwing a different exception, or by removing expected=... in @Test. You'll see that the test fails.

ah, I spotted the behavior in ExpectException, I c...

2009-12-28T07:13:41.129-05:00

ah, I spotted the behavior in ExpectException, I can't figure out tthough that if an exception is thrown from another thread, it gets swallowed somewhere as without the re-throw line above you get a green bar when the exception was thrown, caught (on another thread) so never thrown on the test thread. I figure the test should go red in this case because its expecting a X exception which it doesn't get (as its thrown on another thread). Unless its the ExpectException statement that is still on the main thread...

At least that's what's confusing me at the moment. I'm not explaining it very well, but its got me all in a tiz waz!

No, this is because when you use @Test(expected = ...

2009-12-27T14:14:24.113-05:00

No, this is because when you use @Test(expected = ...), Junit create a statement surrounding the statement executing the test method. It means that when we run statement.execute(), the ExpectedException statement runs and call the InvokeMethod statement. If the latter fails,the ExpectedException statement will check the exception and match it against the expected.

The code
if(throwable != null) throw throwable;
is only required for a failing test throwing an exception.

Did you run the test red above? It seems if you co...

2009-12-27T13:41:46.955-05:00

Did you run the test red above? It seems if you comment out the line

if(throwable != null) throw throwable;

it still runs green, is that a false positive?

Great, I like the completion service version. It w...

2009-12-27T05:59:54.455-05:00

Great, I like the completion service version. It was bugging me that in my version it'd wouldn't return fast (as in the first thread in the list must finish before things continue, when the second in the list may have already finished).

Hi Mathiu, glad to see thar we have arrived to a s...

2009-12-23T16:14:07.273-05:00

Hi Mathiu,
glad to see thar we have arrived to a similar solution(currently I must yet refactorize it and writing some unit test and checking...this version was temporary): http://pastie.org/753201

Yes it's a good idea ! Instead of playing with...

2009-12-23T13:53:52.493-05:00

Yes it's a good idea ! Instead of playing with threads, it can be simply and much more reliable to use instead FutureTask or CompletionService to handle execution and get the results or exceptions thrown.

I've updated this post to give an example.

Thanks !

Great post. How'd you like http://code.goo...

2009-12-23T11:50:27.249-05:00

Great post.

How'd you like

http://code.google.com/p/tempus-fugit/source/browse/trunk/tempus-fugit/src/main/java/com/google/code/tempusfugit/concurrency/RunConcurrently.java

as an alternative? I wanted to try and get any failure thrown on a non-test thread to still fail the test. Its a bit rough and ready at the moment but I had fun coding it!

cheers

Yes you're right. In case the Statement is not...

2009-12-22T10:19:47.961-05:00

Yes you're right. In case the Statement is not an instance of InvokeMethod, I was skipping its call... I am fixing it now.

A little question, shouldn't you call stateme...

2009-12-22T06:49:03.077-05:00

A little question, shouldn't you call
statement.evaluate() (statement is the param)
instead of
frameworkMethod.invokeExplosively(o)?

Probably I'm wrong but it seemed to me that Kent Beck in his blog entry on @Interceptor says that the target and the method parameters are there for additional validation/logging purpose?

Very interesting and useful blog entry! Thank you....

2009-12-21T11:00:12.385-05:00

Very interesting and useful blog entry!
Thank you.

Yes absolutely ! I've fixed the code. Thank yo...

2009-12-04T20:34:22.788-05:00

Yes absolutely ! I've fixed the code.
Thank you !

If go.await() is interrupted, shouldn't you ei...

2009-12-04T06:11:32.446-05:00

If go.await() is interrupted, shouldn't you either throw the exception or at least not execute the actual test?

Sorry! It's corrected.

2009-11-17T09:24:11.869-05:00

Sorry! It's corrected.

Few times you mention "ManageRule" inste...

2009-11-17T02:47:37.096-05:00

Few times you mention "ManageRule" instead of MethodRule.
Cheers

Hi Mathieu, good to know. Thanks. I started to n...

2009-11-11T17:29:54.834-05:00

Hi Mathieu, good to know. Thanks.

I started to notice your blog a while ago.