From: SourceForge.net <no...@so...> - 2007-03-22 18:58:35
|
Bugs item #1582001, was opened at 2006-10-21 18:05 Message generated for change (Settings changed) made by dsaff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=1582001&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Olivier Dagenais (olidag) Assigned to: Nobody/Anonymous (nobody) Summary: Give TimeoutTest.timeoutFailure more time to pass Initial Comment: The test org.junit.tests.TimeoutTest.timeoutFailure was failing on my laptop with the official 4.1 release as follows: """ [java] There was 1 failure: [java] 1) timeoutFailure(org.junit.tests.TimeoutTest) [java] java.lang.AssertionError: expected:<class java.lang.InterruptedException> but was:<class java.lang.Exception> [java] at org.junit.Assert.fail(Assert.java:69) [java] at org.junit.Assert.failNotEquals(Assert.java:333) [java] at org.junit.Assert.assertEquals(Assert.java:101) [java] at org.junit.Assert.assertEquals(Assert.java:112) [java] at org.junit.tests.TimeoutTest.timeoutFailure(TimeoutTest.java:71) (...snip...) """ I grabbed the latest from CVS and I could also reproduce the problem. Temporarily changing line 71 of TimeoutTest.java to the following: assertEquals(result.getFailures().get(0).getException().getMessage(), InterruptedException.class, result.getFailures().get(0).getException().getClass()); ...exposed that execution was indeed going to line 68 of TestMethodRunner.java and a simple Exception was logged (with addFailure) instead of an InterruptedException. I remember from my C++ demo coding days that with some operating systems the best granularity you could get with a timer was about 10 milliseconds, so I started fiddling with the test's numbers, in case execution was being switched at just the right time to miss the timeout. Here are the results of my experimentation: timeout | sleep | result ------------------------ 100 | 200 | fail 200 | 400 | fail 250 | 500 | pass 400 | 800 | pass 1000 | 2000 | pass ...and thus this patch sets the timings to 250/500, which will hopefully go unnoticed by anybody running these tests often. I was not able to reproduce the problem on my desktop computer, although it is running a slightly different version: JDK 1.5 Update 7. You guys may even want to crank it to 1000/2000, just to be on the safe side. Hopefully this won't start a big debate over my laptop being too slow for running JUnit (it's a 2.0 GHz) nor my operating system/software version being suboptimal for it (the problem only manifested itself when running the Ant script on the command line - but not in Eclipse!). FYI, I'm running JDK 1.5 Update 9. HTH, - Oli ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=1582001&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-04-20 18:33:04
|
Bugs item #1582001, was opened at 2006-10-21 18:05 Message generated for change (Comment added) made by dsaff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=1582001&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Olivier Dagenais (olidag) Assigned to: Nobody/Anonymous (nobody) Summary: Give TimeoutTest.timeoutFailure more time to pass Initial Comment: The test org.junit.tests.TimeoutTest.timeoutFailure was failing on my laptop with the official 4.1 release as follows: """ [java] There was 1 failure: [java] 1) timeoutFailure(org.junit.tests.TimeoutTest) [java] java.lang.AssertionError: expected:<class java.lang.InterruptedException> but was:<class java.lang.Exception> [java] at org.junit.Assert.fail(Assert.java:69) [java] at org.junit.Assert.failNotEquals(Assert.java:333) [java] at org.junit.Assert.assertEquals(Assert.java:101) [java] at org.junit.Assert.assertEquals(Assert.java:112) [java] at org.junit.tests.TimeoutTest.timeoutFailure(TimeoutTest.java:71) (...snip...) """ I grabbed the latest from CVS and I could also reproduce the problem. Temporarily changing line 71 of TimeoutTest.java to the following: assertEquals(result.getFailures().get(0).getException().getMessage(), InterruptedException.class, result.getFailures().get(0).getException().getClass()); ...exposed that execution was indeed going to line 68 of TestMethodRunner.java and a simple Exception was logged (with addFailure) instead of an InterruptedException. I remember from my C++ demo coding days that with some operating systems the best granularity you could get with a timer was about 10 milliseconds, so I started fiddling with the test's numbers, in case execution was being switched at just the right time to miss the timeout. Here are the results of my experimentation: timeout | sleep | result ------------------------ 100 | 200 | fail 200 | 400 | fail 250 | 500 | pass 400 | 800 | pass 1000 | 2000 | pass ...and thus this patch sets the timings to 250/500, which will hopefully go unnoticed by anybody running these tests often. I was not able to reproduce the problem on my desktop computer, although it is running a slightly different version: JDK 1.5 Update 7. You guys may even want to crank it to 1000/2000, just to be on the safe side. Hopefully this won't start a big debate over my laptop being too slow for running JUnit (it's a 2.0 GHz) nor my operating system/software version being suboptimal for it (the problem only manifested itself when running the Ant script on the command line - but not in Eclipse!). FYI, I'm running JDK 1.5 Update 9. HTH, - Oli ---------------------------------------------------------------------- >Comment By: David Saff (dsaff) Date: 2009-04-20 14:32 Message: Already ignored. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=1582001&group_id=15278 |