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.
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
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.
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
- Opera has it's own policy file; it is located in Windows under
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:
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
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.
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:
The applets referenced in the pages are located in the
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> 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_typedoes NOT WORK.
- The param
- For browsers that support it, class names can have package prefixes. See
BaseIntegration.csto 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
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
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
The component matcher in FEST-Swing relies on each control to have a
name property specified (using the
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 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.