Make KeyboardShortcutsConfigTest run reliably on Travis #1263
Comments
|
Is it ok if I work on this ? |
|
@dariusf any specific steps to reproduce the issue. Perhaps running together with other guitests because running only the test alone seems to have no problem. Maybe I will try a few more times. |
|
Unfortunately, no, the only thing we have are those stack traces, so the best way might be to reason the problem out. This rarely fails, and passes quite reliably on OS X/my Ubuntu VM. Interactions with other tests may be the cause, since this does rely on global state which other tests can access. |
|
So, the @Test
public void invalidKeySpecified() {
// ...
waitUntilNodeAppears(hasText("Invalid key specified for MARK_AS_READ" +
" or it has already been used for some other shortcut. "));
// ...
}Which uses a test helper method from public void waitUntilNodeAppears(Node node) {
waitUntil(node, n -> n.isVisible() && n.getParent() != null);
}Which in turn uses public static <T extends Node> void waitUntil( final T node, final Predicate<T> condition )
{
waitUntil( node, condition, 15 );
}
public static <T extends Node> void waitUntil( final T node, final Predicate<T> condition, int timeoutInSeconds )
{
TestUtils.awaitCondition( new Callable<Boolean>()
{
@Override
public Boolean call() throws Exception
{
return condition.apply( node );
}
}, timeoutInSeconds );
}
public class TestUtils
{
public static void awaitCondition( Callable<Boolean> condition )
{
awaitCondition( condition, 5 );
}
public static void awaitCondition( Callable<Boolean> condition, int timeoutInSeconds )
{
long timeout = System.currentTimeMillis() + timeoutInSeconds * 1000;
try
{
while( !condition.call() )
{
Thread.sleep( 10 );
if( System.currentTimeMillis() > timeout )
{
throw new TimeoutException();
}
}
}
catch( Exception e )
{
throw new RuntimeException( e );
}
}
} |
|
So |
|
Now, I wonder why the stacktrace says that the NPE is thrown in |
|
|
|
@dariusf You said it might be a problem with global state. Does this mean it is unlikely to be caused by a timing problem? |
|
I'm not entirely sure, but the latter seems more likely. Will take a closer look to confirm. The overload involved there seems to be this one instead: public void waitUntilNodeAppears(Matcher<Object> matcher) {
awaitCondition(() -> findQuiet(matcher).isPresent());
}
private <T extends Node> Optional<T> findQuiet(Matcher<Object> matcher) {
try {
return Optional.of(find(matcher));
} catch (NoNodesFoundException | NoNodesVisibleException e) {
return Optional.empty();
}
}which ends up doing The differing line numbers should be from an old version of the file. There are other parts which don't match up exactly also. If, say, this were a timing problem, is busy-waiting like this a good way to fix it? I'm afraid we're still a bit unclear on best practices for synchronisation. 😛 Thanks for helping us with this! |
The text was updated successfully, but these errors were encountered: