0

I want to run jUnit test cases in a java program and to stop the run after a timeout. To execute the tests I use the run(Request) method of JUnitCore.

The test classes contain methods which take a lot of time and/or do not terminate. Thus, I want to be able to stop the execution.

However, jUnit's pleaseStop flag is only taken in account after a completed test case, the methods can't be interrupted and the content (e. g. used IO resources which could be closed) is not known. Furthermore, I would like to avoid using a process.

Is there any other way to stop the execution of a single test case?

Would it be ok to use Thread.suspend() under the condition that I don't share any resources among threads?

(I've read Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?)

nrainer
  • 2,542
  • 2
  • 23
  • 35
  • For tests it should be fine to suspend a thread as long as it isn't mission critical for the test to fail because of the race conditions. – Gray Apr 15 '13 at 20:31
  • Are you able to improve the code that your testing? If you can alter it so that doesn't "hang" and it will behave itself when resources are unavailable or blocking (ie. add timeouts to your code) you will be better off. What happens with a hung process in production? Also think about adding a "cancel" method for any threads that are processing in an indefinite loop. – Brad Apr 15 '13 at 20:44
  • No, the program's purpose is to run mutation tests, the test cases can't be modified / are unknown. – nrainer Apr 15 '13 at 20:50
  • http://stackoverflow.com/a/2941940 – nrainer Apr 16 '13 at 11:59

2 Answers2

2

Would it be ok to use Thread.suspend() under the condition that I don't share any resources among threads?

I would say that for tests it should be fine to use the deprecated Thread.suspend() method. I think it is important to reiterate the reasons why it is deprecated. You may suspend threads while they are holding locks which may dramatically alter how your code operates and even cause deadlocks.

If possible, I would consider using other mechanisms to achieve the same behavior.

To quote from the javadocs:

Deprecated. This method has been deprecated, as it is inherently deadlock-prone. If the target thread holds a lock on the monitor protecting a critical system resource when it is suspended, no thread can access this resource until the target thread is resumed. If the thread that would resume the target thread attempts to lock this monitor prior to calling resume, deadlock results. Such deadlocks typically manifest themselves as "frozen" processes. For more information, see Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?.

Gray
  • 115,027
  • 24
  • 293
  • 354
  • What do you mean with "it is fine for tests"? The program as such must work properly and be reliable. – nrainer Apr 16 '13 at 16:25
  • Is my assumption correct, that I won't cause any deadlocks because no shared objects among threads exist? – nrainer Apr 16 '13 at 16:26
  • I was trying to differentiate between using it in live code versus Junit. Using those methods are fine for tests as long as you understand the limitations @nrainer. – Gray Apr 16 '13 at 16:28
  • If the threads enter any `synchronized` blocks or lock any locks then you are going to have a possible problem even if there is no shared objects @nrainer. – Gray Apr 16 '13 at 16:29
  • I' m not sure whether I understand. The thread will hold a lock, however it is the exclusive user of the locked objects. Thus, no other threads will run into a problem. Is that correct? – nrainer Apr 16 '13 at 16:43
  • Yes, you are correct @nrainer if no one else is going to get the lock you will be fine. – Gray Apr 16 '13 at 17:22
1

You can use the timeout parameter on individual tests or the Timeout rule on all tests in a class. See the doc here Timeout-for-tests.

Charles François Rey
  • 52
  • 1
  • 4
  • Well, that requires to add annotations to the test class. My test cases are unknown at compile time... – nrainer Apr 15 '13 at 21:06