Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to Junit Test Runnable or Thread

 
junchen liu
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How can I test Runnable classes?
I normally uses NetBeans to automatically generate
Junit test cases,

public void testRun() {
System.out.println("run");
MyRunnable instance = null;
instance.run();
}

The code doesn`t make any sense isn`t, how can
I test Thread properly?
 
Daesung Park
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know how Netbeans generates code, but there is nothing special in testing Thread or Runnable.
Is MyRunnable a concrete class implememting Runnable?
If so, you can do "new Thread(instance).start()". Of course "instance" should be initialized properly.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What exactly do you want to test?
 
junchen liu
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
first, thanks both of you for the replies.
My problem is that, Junit test normally uses

assertNotNull(result);
assertEquals(result, expectedResult);
assertNotSame(result, expectedResult);

or simply

try{
instance.methodUnderTest();
} catch(Exception e){
fail("fail because exception thrown");
}

As in Java a Runnable
1> never ever returns any value
2> or throws any exception

what can we do?

a Callable does return value, and thrown exception. Does it mean that we have to
cast each runnable to callable before test?
[ February 22, 2008: Message edited by: junchen liu ]
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34839
369
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junchen,
Part of this is "how do I test a void method" - where you test the side effects. For example, does the method change some state that you can access through a getter?

The thread specific part is how to tell when the thread is done. You can either call the method's run method directly as if it were regular Java code (instead of a thread.) If you want to test it as a thread (say you are starting a few of them), you can have a loop (and sleep for a bit) and check for whether the thread is done. Then you can do your asserts when it is done. If you go the later route, be sure to have a timeout in case your thread never returns. JUnit 4 and TestNG support timeouts out of the box. In JUnit 3.8, you will need to write a loop yourself.
 
junchen liu
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good explanation! I am getting there I think.

however there are few final questions left

>call the method's run method directly? what difference it would make, I mean compare
to pass the Runnable to a thread? apart from I can not use thread.sleep(). susped() etc?

>have a loop (and sleep for a bit) and check for whether the thread is done. Then you can do your asserts when it is done. What about a thread Never done? such as a tcp client thread which keep receiving socket data? it should never done, unless the application terminates.

>JUnit 4 and TestNG support timeouts out of the box. Can I have a sample please.
just a web link woiudl be fine.

Again thanks a lot for all your time!!
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34839
369
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by junchen liu:
what difference it would make, I mean compare
to pass the Runnable to a thread? apart from I can not use thread.sleep(). susped() etc?

That's the only difference. For a thread that ends, this gives you the synchronous queue that something has happened. For unit testing (where you wouldn't want to sleep), this is very important. For integration testing, it is often helpful, but not always critical.


What about a thread Never done? such as a tcp client thread which keep receiving socket data? it should never done, unless the application terminates.

In that case, you would want to test with a real thread (and not the simulated one described above.) You would do something like:
1) start the thread
2) send something to the socket
3) sleep a bit to give the thread time to work
4) check whether the thread did what it was supposed to do with the socket data yet and repeat step 3 it hasn't yet
5) stop the thread in your tear down to free up the port
5) after a certain amount of time, fail the test to give up waiting


Can I have a sample please.
just a web link woiudl be fine.

Articles describing the timeout feature of junit and testng.
 
junchen liu
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Jeanne ! It was great answer!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic