sm4 sm4 - 1 year ago 145
Java Question

AssertJ Swing - kill all fixtures

Is there a way how to kill all AssertJ created fixtures, or how to prevent hanging, when creating a new one? When trying to migrate a lot of legacy GUI tests to AssertJ Swing, I have to often face the following deadlock:

"main" #1 prio=5 os_prio=0 tid=0x0000000002080000 nid=0x9c waiting on condition [0x00000000024cd000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0000000547049720> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(
at org.assertj.swing.lock.ScreenLock.acquire(
at org.assertj.swing.core.BasicRobot.acquireScreenLock(
at org.assertj.swing.core.BasicRobot.robotWithCurrentAwtHierarchy(
at org.assertj.swing.fixture.AbstractWindowFixture.<init>(
at org.assertj.swing.fixture.FrameFixture.<init>(

This is of course caused by wrong usage of fixtures, when a new one is being created while another one is still active. However, this deadlock complicates the migration.

sm4 sm4
Answer Source

After exploring the framework more, I have realized that

  • I do not need to use locking
  • It is possible to release the lock, if I create the robot myself

Now I am using this code to create the fixture:

assertJRobot = BasicRobot.robotWithCurrentAwtHierarchy();
frameFixture = new FrameFixture(assertJRobot, appFrame());

And this code when I need to create another fixture, while the other test did not release the lock but otherwise closed windows, and cleaned up everything else:

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download