Skip to main content

Again: how to unit test code in SwingUtilities.invokeLater?

3 replies [Last post]

just ran into it again: this time the goal is to test that the
TreeTableModelAdapter maps the received TreeModelEvents into correct
TableModelEvents. The only way (I can think of) is to listen to the
adapter. The adapter has to fire in SwingUtilities.invokeLater (okay,
the "has to" is open to arguments, but that's what it is doing and until
now nobody came up with different and reliable solution).

Consequently, I have to wrap the asserts into a invokeLater as well:

<br />
void testEvent() {<br />
   ... setup stuff<br />
   model.setRoot(...);<br />
   SwingUtilities.invokeLater(new Runnable() {<br />
      public void run() {<br />
        assertTrue("event type must be structureChanged ",<br />
           report.isStructureChanged(report.getLastEvent()));<br />
      }<br />
<p>}<br />

(more in the table event notification tests in JXTreeTableUnitTest)

while this works (kind of) it freaks the testrunner: the test always
appears as passing, if the invoked assert really fails, the error
stacktrace appears on the system.out. Which is understandable, but not
what I would want from automatic testing.

How/what to do to let the failure turn up in the runner?


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


> What about invokeAndWait() instead?

good idea - that seems to be what I had been looking for: failing tests
in the invoke now to appear in the testrunner as failures. Cool :-)

Thanks everybody for guiding me through thread jungle (which I'm always
lost in)


To unsubscribe, e-mail:
For additional commands, e-mail:

Joined: 2003-06-13

What about invokeAndWait() instead?

Seem to remember TestNG is generally lauded for its concurrency testing abilities whereas its a recognised weakness of JUnit - not that that's of any practical use right now . Well not unless you add another layer of testing to the build.

- Richard

Joined: 2006-06-08

invokeAndWait won't help either unless to bring the exception (assertion failures are exceptions) back to the JUnit thread.

Here's an example that I keep for the team on how to do just that:
* This is an example of how to create a JUnit test that works for
* multi-threaded code.
public class JUnitThreadExample {
private volatile Throwable threadException;

* @throws InterruptedException
* if an error occurs
@Test(expected = AssertionError.class)
public void testThreading() throws InterruptedException {
Runnable r = new Runnable() {
public void run() {
try {
throw new RuntimeException();
} catch (Throwable t) {
threadException = t;

Thread t = new Thread(r);

if (threadException != null) {
StringWriter s = new StringWriter();
threadException.printStackTrace(new PrintWriter(s));

I haven't tried with invokeAndWait, but it will need to use this thread logic to obtain the error.