mbien commented on code in PR #4112:
URL: https://github.com/apache/netbeans/pull/4112#discussion_r1043143230
##########
platform/openide.util/test/unit/src/org/openide/util/TaskTest.java:
##########
@@ -21,25 +21,184 @@
import java.util.logging.Level;
import java.util.logging.Logger;
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
+import static org.junit.Assert.fail;
+import org.junit.Test;
import org.netbeans.junit.Log;
-import org.netbeans.junit.NbTestCase;
-import org.openide.util.Exceptions;
-import org.openide.util.Task;
+import static java.lang.System.currentTimeMillis;
+import static org.junit.Assert.assertNotEquals;
+import static org.junit.Assert.assertNull;
+import static org.junit.Assert.assertSame;
+import org.junit.Ignore;
-public class TaskTest extends NbTestCase {
- private Logger LOG;
- public TaskTest(String testName) {
- super(testName);
+public class TaskTest {
+ private static final Logger LOG =
Logger.getLogger("org.openide.util.TaskTest");
+
+ private volatile boolean runHasBeenExecuted = false;
+ private volatile Task executedListenerTask = null;
+
+
//--------------------------------------------------------------------------
+ private static void assertFinished(final Task task) {
+
+ assertTrue(task.isFinished());
+ }
+
+
//--------------------------------------------------------------------------
+ private static void assertWaitFinishedReturnsImmediately(final Task task) {
+
+ final long begin = currentTimeMillis();
+ task.waitFinished();
+ final long duration = currentTimeMillis() - begin;
+ // shorter than 1 milisecond
+ assertEquals("The Task.waitFinished() took longer than milisecond. "
+ + "This is not neseserily a bug.", 0, duration);
Review Comment:
I don't like this. First of all, `System.currentTimeMillis()` is not
monotonic. It can run backwards in some situations, e.g. when CPU cores change.
This also essentially is trying to measure a 1ms delta which isn't even
possible resolution wise. However bad resolution can be even an advantage here
and cause less failures. (timer accuracy on windows for example has been
traditionally very bad, every 3d engine has its own workaround for that)
You can literally call `currentTimeMillis`() twice in a row and get
different values as this quick test demonstrates:
```java
public static void main(String[] args) {
while (true) {
if (System.currentTimeMillis() != System.currentTimeMillis()) {
System.out.println("test failure: someone please restart the
test job");
}
}
}
```
`nanoTime` can be monotonic if the platform/HW supports it and if its
enabled - I don't really know how the cloud is set up here or how other OSes
outside of linux are set up.
We already have many unreliable tests as you can see, the current run failed
for example in several jobs. Even if it rarely fails it is a problem since
someone has to play whack a mole and both (limited) CPU time and dev time is
wasted.
So my intuition here is to rather not add more unreliable tests.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
