Marvin Rabe

Testing UI with FEST

I was always asking myself what could be the best way to automate UI testing. Some days ago I was looking for tools for my first bigger Java Swing project. I checked out many different tools and I thought that FEST could be the best one.

FEST is a big collection of libraries to aid software testing. It is especially an UI testing tool for Swing applications. FEST was released under the Apache 2.0 license. You can use FEST together with JUnit. I will explain how to use it in today’s article.

Though it has more to offer than UI testing, I only focused on that.

Setting up IntelliJ##

To get it up and running in your project, you have to download the library and add it to the testing dependencies.

Note that every JAR file has to be added, not only fest-swing. If you want JUnit support you also have to add the fest-swing-junit and junit files.

With IntelliJ you do it this way:

  1. Add JAR files to your project libraries (File -> Project Structure -> Libraries)
  2. Afterwards add library to your build dependencies (File -> Project Structure -> Modules -> Dependencies)
  3. You have to set the scope to “Test” otherwise the test libraries will be available in your production code.

After that your able to create you first test case.

Create test case

Create a test case with JUnit for your Swing UI class and add the following setUp and tearDown methods. They will initialize the needed FEST objects.

    private ApplicationLauncher app;
    private Robot robot;
    private FrameFixture window;

    protected void setUp() throws Exception {
        // Start app
        app = ApplicationLauncher.application(App.class);

        // Setup robot
        robot = BasicRobot.robotWithCurrentAwtHierarchy();

        // Find the main window
        FrameFinder ff = WindowFinder.findFrame(MainView.class);
        window = ff.using(robot);

    public void tearDown() {

The java Robot class will generate native system input events (like mouse clicks). With WindowFinder you get the current window. You use the results from the WindowFinder as an entry point for looking up JComponents in your Swing UI.

Testing UI

So far I only created some simple tests with this library. The examples are for this reasons pretty basic.

The following example will look for an enabled and visible button with the label test. Afterwards the button will be clicked and a dialog window will open. The dialog has to display the text button 1 to fulfill the requirements.

	// Clicks on specific button
		new GenericTypeMatcher<JButton>(JButton.class){
			protected boolean isMatching(JButton button){
				// Check that the button is visible
				return "Button Label".equals(button.getText()) &&
						button.isEnabled() &&
	// Check if right message is displayed
	window.dialog().optionPane().requireMessage("button 1");
	// Close dialog

If you assigned a name to your button, there is a much simpler way:


Please don’t mix up label and name. The label is the visible text on the button and the name is an internal identifier you have to set manually (optional).

Of course there are more elements you could validate with FEST. But to get a basic feeling for FEST this is all you need to know.


I was astonished after running my first test. It looked like magic. I never used any UI testing tools before. But after I had given more thoughts on it I’m not so enthusiastic anymore. The missing documentation is a big problem. I needed some time before I got into it by trial and error. Also the FEST project appears to be abandoned at the moment.

Although there are these few problematic areas, I think it is way better to write a test with FEST than to write no test at all. It is usable and I diddn’t encountered any critical bug while evaluation. I will use it on my current (not so important) Swing project and will draw some final conclusions in the end.