File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Threads and Synchronization and the fly likes Threads not forking in a JUNIT test case Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Threads not forking in a JUNIT test case" Watch "Threads not forking in a JUNIT test case" New topic

Threads not forking in a JUNIT test case

Jeff Gaer
Ranch Hand

Joined: Jun 04, 2001
Posts: 103
I have a Junit Test case that is testing some client server code. I create a separate threads to emulate the client and the server and expect to see operations interspersed. However they seemed to run sequentially. Running with debug on in eclipse, it looks as so all the calls are stacked in the same (main) thread. I would have expected that after the new Thread(new myRunnabled()).run a new thread to appear in the debug window. Here's is the stack trace from the main thread and its evident that after the run() methid is called the runnable is executing in the main thread.

The following code executes

Thread thread=new Thread(new Runner());

The first few lines of runnaer are

class Runner implements Runnable{

public void run() {
boolean first=true;
try {

I would expect Runnner to be running in its own thread, but the stack trace indicates it is exectuing in the main thread line: 662 line: 78
MockISTest$ line: 140 line: 662
MockISTest.TestMockIS() line: 85

The full stack trace of the main thread follows.
Thread [main] (Suspended)
SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int) line: not available [native method][], int, int) line: 129 line: 182
AIResponse$Builder(AbstractMessageLite$Builder<BuilderType>).mergeDelimitedFrom(InputStream, ExtensionRegistryLite) line: 276
AIResponse$Builder(AbstractMessage$Builder<BuilderType>).mergeDelimitedFrom(InputStream, ExtensionRegistryLite) line: 705
AIResponse$Builder(AbstractMessageLite$Builder<BuilderType>).mergeDelimitedFrom(InputStream) line: 288
AIResponse$Builder(AbstractMessage$Builder<BuilderType>).mergeDelimitedFrom(InputStream) line: 697
AIResponse.parseDelimitedFrom(InputStream) line: 202
MockIS$ line: 87 line: 662 line: 78
MockISTest$ line: 140 line: 662
MockISTest.TestMockIS() line: 85
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 597
TestMethod.invoke(Object) line: 59
MethodRoadie.runTestMethod() line: 98
MethodRoadie$ line: 79
MethodRoadie.runBeforesThenTestThenAfters(Runnable) line: 87
MethodRoadie.runTest() line: 77 line: 42
JUnit4ClassRunner.invokeTestMethod(Method, RunNotifier) line: 88
JUnit4ClassRunner.runMethods(RunNotifier) line: 51
JUnit4ClassRunner$ line: 44
ClassRoadie.runUnprotected() line: 27
ClassRoadie.runProtected() line: 37 line: 42
JUnit4TestClassReference(JUnit4TestReference).run(TestExecution) line: 50[]) line: 38
RemoteTestRunner.runTests(String[], String, TestExecution) line: 467
RemoteTestRunner.runTests(TestExecution) line: 683 line: 390
RemoteTestRunner.main(String[]) line: 197

Sun Certified Java Programmer Java 2<P>Jeff Gaer
Richard Tookey

Joined: Aug 27, 2012
Posts: 1166

You start() threads running so that should be

Just calling the run() method does as you say - it executes the code sequentially.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
subject: Threads not forking in a JUNIT test case
It's not a secret anymore!