This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Jiri, it seems that after your integration: #78892 - second attempt - setUp() and tearDown() run also in AWT event thread if runInEQ() returns true. It is done in runBare method to which was also moved code from runTest method. Members: manifest.mf:1.16->1.17 src/org/netbeans/junit/NbTestCase.java:1.47->1.48 test/unit/src/org/netbeans/junit/RunInEventQueueTest.java:1.4->1.5 The test: Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 9,81 sec Testcase: testRunsInAWTThreadAndShallFailWith5sDelay(org.netbeans.junit.TimeOutTest): FAILED ok: true count: 1 for testRunsInAWTThreadAndShallFailWith5sDelay junit.framework.AssertionFailedError: ok: true count: 1 for testRunsInAWTThreadAndShallFailWith5sDelay at org.netbeans.junit.TimeOutTest.run(TimeOutTest.java:73) Test org.netbeans.junit.TimeOutTest FAILED /doma/jarda/netbeans-src/nbbuild/templates/common.xml:458: Some tests failed; see details above. BUILD FAILED (total time: 13 seconds) is broken. Maybe you should revert your changes and try for the 3rd time? In any case please make sure that you really run all the tests before your commits next time. Thanks.
You are right I didn't run nbjunit tests before integration. I am sorry for that and I will do it next time. But looking at TimeOutTest I found out that the test is probably wrong. It passed by mistake before my integration. You probably wanted to check expectedResult property but it is only set and not checked. Or am I wrong?
Ok. Next time please run the tests before. I guess that the problem with your change is that tearDown now runs in AWT and the code waits for tearDown to finish. However in the Test the AWT is blocked by the runnable that has not yet timed out. Now the question is what to do with the code? When using timeout, shall the tearDown be blocked? Imho, it shall not, otherwise there is no timeout and the test can block for ever. Possible solution is to run tearDown in non-awt thread in case of timeout. Any other idea?
I see. The best would be to interrupt runnable running in AWT. But I am afraid it is not possible.
In the given test case sending Thread.interrupt() would help, as the test just does Thread.sleep(...). But I do not think it is good solution, the timeOut() has been introduced to dead with real deadlocks and those may not be interruptable. I am afraid there are just two choices: - either not call tearDown at all - call it in another thread than AWT
Or restrict setUp and tearDown by the same timeout as the test itself. Then it will not be blocked even when AWT is busy forever.
When test ran in AWT and timeout expires, tearDown was blocked until AWT was blocked. Now tearDown and setUp can be interrupted if timeout expires. It should not be blocked anymore when test is run in AWT and timeout is used. /cvs/xtest/nbjunit/manifest.mf,v <-- manifest.mf new revision: 1.18; previous revision: 1.17 done Checking in src/org/netbeans/junit/NbTestCase.java; /cvs/xtest/nbjunit/src/org/netbeans/junit/NbTestCase.java,v <-- NbTestCase.java new revision: 1.52; previous revision: 1.51 done Checking in test/unit/src/org/netbeans/junit/TimeOutTest.java; /cvs/xtest/nbjunit/test/unit/src/org/netbeans/junit/TimeOutTest.java,v <-- TimeOutTest.java new revision: 1.3; previous revision: 1.2