Skip to end of metadata
Go to start of metadata

FEST-Swing provides base TestCase classes that takes care of most of the plumbing involved when writing a GUI test. As usual, this feature supports both TestNG (via FestSwingTestngTestCase) and JUnit (via FestSwingJUnitTestCase.)

In general, the provided TestCases do the following:

  1. Install FailOnThreadViolationRepaintManager to check that all access to Swing components is performed in the EDT
  2. Creates a new Robot, using a new component hierarchy
  3. Cleans up resources: releases the semaphore that ensures sequential test execution

Warning

Icon

When using a base TestCase, do not create a new Robot. The base TestCase creates one for you. If there is more than one Robot in your test, only the first one will have access to the screen, while the rest will block till they get the 'screen lock'. A Robot can be created manually or indirectly using the constructors FrameFixture(Frame) or DialogFixture(Dialog). Please use the overloaded versions that take a Robot as parameter, passing the already created Robot (by calling the method robot().)

As reference, the following code listing shows a GUI test that is not using extending a TestCase:

The following code listing shows the same test, extending FestSwingTestngTestCase:

See also:

9 Comments

  1. There's a typo near the beginning of both code listings. The line:

    private FrameFixure window;

    should be:

    private FrameFixture window;

  2. Thanks so much Alister! I just fixed the typo (smile)

  3. In the 1.2.1 jar there is no class org.fest.swing.testng.testcase.FestSwingTestngTestCase

    instead, did you intend to write org.fest.swing.testing.FestSwingTestCaseTemplate?

    Was this class name changed between versions and these pages did not get updated?

  4. Hi Jonathan,

    The problem is that you need to add the jar fest-swing-testng to your classpath. Please visit the link "Jar Files Explained" above, in the section "See Also."

    I've been trying my best to organize the documentation in a way that is easy to find information. I still think that our docs need improvement, but I can't find a better way to organize them.

    Suggestions are always welcome (smile)

    Cheers!

  5. Understood.  We rely on Maven so by adding this did the trick:

    <dependency>
    <groupId>org.easytesting</groupId>
    <artifactId>fest-swing</artifactId>
    <version>1.2.1</version>
    <scope>test</scope>
    </dependency>

    <dependency>
    <groupId>org.easytesting</groupId>
    <artifactId>fest-swing-testng</artifactId>
    <version>1.2.1</version>
    <scope>test</scope>
    </dependency>

  6. It's pretty doable. Can you please file a ticket as a reminder for me?

    Thanks!

  7. After thinking about it for a bit, AFAIK, if you just specify fest-swing-testng as a dependency in your pom, it will automatically bring fest-swing. Would that be good enough, or would you still prefer a consolidated jar?

  8. Good point.  Only the dependency fest-swing-testng is needed.  There is no need for a consolidated jar but I do agree with your desire for documentation improvements.  

  9. Hi Alex,

    FYI, the link to FestSwingJUnitTestCase (in the first paragraph) seems to be broken.

    Thanks for all the documentation, really useful.

    Shaun