Comments on: Writing EDT-safe Swing UI tests

By: Alex Ruiz

Alex Ruiz — Mon, 05 Jul 2010 03:35:26 +0000

I have found that “invokeAndWait” can create deadlocks in test code. I haven’t looked into in detail since FEST offers similar behavior without that limitation.

The trick is to execute line #2 in the EDT and wait till all the events in the EDT has been consumed before executing the code in #3.

How to do it will take probably more than one post to explain. I’d suggest you to fork the code in FEST, especifically the org.fest.swing.edt package. Don’t worry about license, it is Apache 2.0, which is business friendly :)

Cheers,

By: Jimmy

Jimmy — Sun, 04 Jul 2010 05:01:04 +0000

[Sorry for the duplicate comment, I misspelled my email address in earlier one]

Hi Alex,

I was so glad to find an article which talks about writing EDT safe swing tests. This is exactly the challenge that I am facing currently. Unfortunately, I am not using FEST, so the methods described here does not solve my problem. I would appreciate if you could help me in understanding what I am doing wrong in my test.

Here is what I have in my JUnit test:

@Test
public void testSomething()
{
// Line 1: do something
// Line 2: Execute code which generates mouseDragged event
// Line 3: Verification that mouseDragged event is generated
}

What I notice is that my Line 3 gets executed before the mouseDragged method (which does get executed but little late). I tried adding my verification code on to EDT by wrapping it in InvokeAndWait but it still does not help.

In general I am looking for some basic guidelines on what is the best way to avoid such situation. What exactly should be wrapped in InvokeAndWait and what should not in testing?

Any help is much appreciated.

- Jimmy

By: Alex Ruiz

Alex Ruiz — Fri, 05 Feb 2010 03:11:18 +0000

I apologize for the confusion. I’m a TestNG user and it doesn’t require the @BeforeClass method to be static. I should have specified that.

Thanks!

By: Alex Ruiz

Alex Ruiz — Fri, 05 Feb 2010 03:08:00 +0000

@RunsInEDT is simply there for documentation purposes. While working on FEST, I found it pretty difficult to know which method is being ran in the EDT and which on the current thread. I use the annotation just as a reminder of which methods/classes are EDT-safe.

By: Luke Nezda

Luke Nezda — Fri, 05 Feb 2010 03:06:37 +0000

@BeforeClass requires decorated method be static: sample code here and copy+pasted to http://www.ibm.com/developerworks/java/library/j-swingtest/ should be:

@BeforeClass public static void setUpOnce() {
FailOnThreadViolationRepaintManager.install();
}

By: Luke Nezda

Luke Nezda — Fri, 05 Feb 2010 03:02:33 +0000

Does combo of JUnit 4 @Test and @RunsInEDT do this?

By: Alex Ruiz

Alex Ruiz — Fri, 15 Jan 2010 18:37:49 +0000

Hi Bruce,

We currently don’t support such feature, mainly because there haven’t been any requests for it.

I can see this feature is useful, as long as you don’t use the AWT Robot (or FEST’s Robot,) because they cannot run in the EDT.

Can you please file a ticket at http://jira.codehaus.org/browse/FEST ? I’d like to keep this conversation there :)

Thanks!

By: Bruce Alspaugh

Bruce Alspaugh — Fri, 15 Jan 2010 18:28:34 +0000

Is it possible to somehow tell the test runner (either JUnit or TestNG) that you would like to run a particular test method on the EDT? Maybe specify in the annotation that the test is supposed to be submitted to a java.util.concurrent.Executor that executes its tasks on the EDT. In other words say something similar to:

@Test(executor=SwingExecutor.class)
public void testMySwingComponentOnEDT() throws Exception {
// all this test code gets run on the Swing EDT
}

The test runner will wait for the test method to finish to see if it throws an exception. If the test method throws an exception, it will be re-thrown back onto the original test runner thread. I think it would make the test code cleaner if we could avoid all the nested inner classes.

By: a

Thu, 03 Dec 2009 12:30:11 +0000

nice post but
execute(new GuiTask() {
public JLabel executeInEDT() {
myCheckBox.setSelected(true);
}
});
should be
final myCheckBox = ….;
execute(new GuiTask() {
public voidexecuteInEDT() {
myCheckBox.setSelected(true);
}
});

By: Alex Ruiz

Alex Ruiz — Thu, 19 Nov 2009 13:04:37 +0000

Another good catch! :)

In the case of ‘focus’, that code was written before GuiActionRunner was introduced to FEST. Currently it waits till the component has focus, and fails if the component didn’t get it.

You are right, it should call ‘waitForIdle’ :)

Now that I revisit this method, I’m not sure ‘waitForIdle’ is good enough, since requesting focus is not a guaranteed action (per Swing Javadocs.) ‘waitForIdle’ will wait till the EDT has no actions to process, but the component might never get the focus. In the case of testing, this is a big issue, since tests would expect a component to have focus.

In short, I need to call ‘waitForIdle’ *and* check if the component has focus :)

(Can you please file a ticket?)

Thanks Per!