Skip to end of metadata
Go to start of metadata


In-browser applet testing can now be accomplished using FEST-Swing in conjunction with Selenium. Most modern browsers with support for the latest Java Runtime Environments (1.6.x) have supplementary support for the Sun LiveConnect specification, albeit to varying degrees of compliance. Using the ability to call into applets and receive responses using javascript, Selenium can be used to drive FEST-Swing which provides a unified way of testing web applications which consist of standard html and embedded applets.

Full JDK6:LiveConnect Specification


At this time, only Selenium 1.0.1 is supported. Both Selenium Core and Selenium RC are used extensively in the automation process. The Selenium IDE tool is NOT used. Future versions of Selenium which use the Webdriver framework will likely require extensive modification.


This project was developed to support an ASP.NET business intelligence application in a corporate environment which consists of dynamically generated multi-frame pages in which Java applets are used to provide rich client side behavior. As such, the focus was to ensure full support for Internet Explorer. Luckily, IE provides the most complete LiveConnect implementation. Although tests have been provided to run against FireFox, Safari, and Opera, varying degrees of implementation of LiveConnect specification mean that these browsers do not fully support FEST-Selenium. Hopefully, future iterations of these browsers will correct these limitations.


Have a look at the fest-selenium/src/dotnet/JavaSelenium/IntegrationTests/BaseIntegrationTests.cs source to see where specific browsers fail their LiveConnect implementations.


The latest stable Selenium server release (1.0.1) does not work against FireFox 3.6.x/Safari 5/Opera 10.6. There seems to be a problem initializing connections to these browsers.


The JavaSelenium project allows the creation of test cases. The Adapter and Command patterns were employed to create the core JavaSelenium implementation using C#. Like FEST-Swing, a fluent interface was employed to provide a convenient and readable API. The goal was to produce test code that reads like series of user operations and to use a consistent grammer for test specification. For the most part, Selenium calls were mapped to their FEST-Swing equivalents.


In addition to using the JavaSelenium to generate test code, applets must be instrumented to use the JAppletFixture supplied by fest-swing. This was accomplished in our project using an interface:

Applets were then implemented with SeleniumTestable interface:



The current version of Selenium (1.0.1) relies extensively on proxy injection. As a side-effect, Selenium is not able to determine when a multi-frame page is fully rendered and attempts to execute commands sometimes when the DOM is invalid. This leads to spurious test execution failures (false negatives). To minimize the occurrence of these errors, it is highly recommended that UIMapping feature of Selenium be avoided.

In addition, the JavaSelenium implementation provides for a Wait delegate to use in order for the application under test to specify it's valid states. In practice, this requires the implementation of page state counters set programmatically through javascript.

Browser Permissions

One of the difficulties of running applets in the browser is the security model for applets. Due to the nature of using the awt.Robot for Swing automation, applets required elevated JRE permissions to perform its work. This can be accomplished by using signed jars or modifying the JRE permissions. Signing jars will not be covered here as there is sufficient on-line documentation to provide guidance.

Changing the JRE security policy depends on the browser you are using.

  • For IE/Safari/Firefox, a java.policy file is required in the %USER%\Application Data\Sun\Java\Deployment\security directory.
  • Opera has it's own policy file; it is located in Windows under C:\Program Files\Opera\classes\Opera.policy.

In both cases, the contents should be as follows:

These permissions give just enough privileges to allow FEST-Swing to do its work. If security is not a concern, you can also grant full privileges:

JRE Minimum

The LiveConnect specification relies on having the option "Enable the next-generation Java Plug-in" option being enabled. This was introduced in the 1.6.0_13 JRE update. Only this version and newer are supported by FEST-Selenium. You can try older versions, but your mileage may vary.


The FEST-Selenium module contains the necessary resources to run integration tests which provide examples of how to use the JavaSelenium adapter against real applets. All of the necessary files are located in the fest-selenium/resources directory.

Webserver Requirements

Simply copy the contents of the resource directory somewhere convenient on your webserver. For the purposes of the integration tests, IIS 6.0 was used, although any other webserver should work equally well.

LiveConnect Tests

As mentioned previously, a browser must fully support the LiveConnect specification. As part of the included resources, there are a number of test pages that can be used against a browser to see whether or not it supports the spec. All of the tests have been aggregated on the liveconnect.html page, but the individual tests are still accessible through the following pages:

  • ArrayAccess.html
  • MethodInvocation.html
  • PackageAccess.html
  • JavaJSTest.html

The applets referenced in the pages are located in the examples.jar.

Any browser which fails these tests is likely to be unsupported by the FEST-Selenium module.

Applet Test Page


Contains a simple page with various applet controls. Care must be taken when specifying the applet in html. The <applet> element has been deprecated; all Java applets should be specified using the <object> element. There is however significant variation in how browsers deal with the <object> attributes.

<object> with attributes only

This is similar to the usage of the deprecated <applet> element is not supported by the 'official' specifications. IE however, still honors this convention. Other browsers may allow this as well.

<object> with <param> to specify java archive parameters

This is the canonical way to specify applet parameters. The use of the java_archive parameter is not well documented however. The type attribute is required.

  • The param java_type does NOT WORK.
  • The param java_code and code are interchangable.
  • For browsers that support it, class names can have package prefixes. See BaseIntegration.cs to see which browsers support this.

Applets can be located within the same jar or be contained in their own jars.


Contains a number basic Swing applets distributed by Sun for testing purposes. These applets demonstrate the various types of controls that can be automated in the browser using FEST-Swing. The source code for these applets can be found under fest-selenium/src/resources/src/com/aclaro/test.

Integration Tests

There are two sets of integration tests. The tests in BaseIntegrationTest.cs exercise various browsers basic ability to support applet testing. This requires that the browsers be installed on the machine running the tests. In addition, you may need to change the URL and APPLET_URL string constants to reflect your webserver installation of the resource files.

The tests in ActionIntegrationTest.cs exercise the various operations that can be automated using the JavaSelenium adapter.

Both tests require a running Selenium server and NUnit. If you are using Visual Studio 2008, you will need to update the JavaSelenium solution.


The JavaSelenium adapter relies heavily on the GetEval method in Selenium to emit javascript which is used to communicate with the JAppletFixture implemented by applets. Selenium core is used to establish the testing session with the system under test and provide testing facilities for html controls.

The component matcher in FEST-Swing relies on each control to have a name property specified (using the setName() method).

The CheckBoxPanel used above also specifies names for each of the components that it includes in its component hierarchy:

Sending an automation command to the applet requires specifying the component to be manipulated to a command object JavaAction. The JavaAction object encapsulates all possible commands that can be run against a component. Generics are used with some commands to ensure that it can be applied to specific component.

  • No labels

1 Comment

  1. Edit: Sorry, nonsense.