Configuring an Oracle ADF Project for Selenium testing

Running Selenium testing against an ADF application requires direct interaction with the HTML DOM, JavaScript and CSS. An ADF application is normally optimised for performance and scalability which means CSS classes and javascript are minified and obfuscated. This makes testing with Selenium very difficult and brittle.

Fortunately you can configure quite a few settings in your project's web.xml file to make it more development friendly. I've written about these before but some are even more important for automated testing. The ADF Faces documentation also states a number of configuration changes have to be made for automated testing.

These are the settings to change when using automated testing:

• oracle.adf.view.rich.automation.ENABLED should be set to true in web.xml. This ensures a javascript client component is created for each ADF component regardless the value of the clientComponent attribute on the JSF component. This makes interacting with the page from Selenium much easier. It also seems to enable some other client and server side features. Search for isAutomationEnabled in the ADF source code to get a feeling for things that will change when enabling this. One of the things it enables is to find objects using scope IDs (also known as Sub IDs). This is explained in the Oracle Application Testing Suite Open Script User Guide.
  For this to work you also need to put adf-richclient-automation-11.jar in your project classpath. The simplest way is to just put this JAR in the WEB-INF/lib folder of your project. The file itself can be found in JDEV_HOME/oracle_common/modules/oracle.adf.view_12.1.3/
• org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION to true in web.xml which will disable the compression of CSS classes like af_button to something like x7k. Having readable and deterministic CSS class names makes it possible to use CSS selectors in your Selenium scripts.
• org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT to true in web.xml o disable the minification of ADF's javascript files. This gives you human readable javascript which makes it easier to figure out how to interact with those scripts from Selenium. You should also get a copy of the ADF Source code from Oracle Support so you even have the versions with all the inline comments in place. But don't let this scare you. For simple testing scenarios you won't be needing javascript interactions. It's just when you want to go all the way and have very detailed interactions or tests with ADF components.
• javax.faces.PROJECT_STAGE to Development in web.xml as your application will otherwise fail to start since you have enabled a number of development-only features. You can revert this to Production with deployment plans for other environments.
• The aforementioned Oracle Application Testing Suite documentation also advises to set animation-enabled to false in trinidad-config.xml. This is not only to speed up the running of the testing script as it won't have to wait for the animations but will also make sure tests don't fail as they want to interact with things like tree nodes before the expanding animation of a tree node is finished. In my own testscripts I also make sure to execute the javascript AdfPage.PAGE.setAnimationEnabled(false) on each page for situations where we forgot to set this parameter. Unfortunately values in trinidad-config.xml cannot be overridden with deployment plans, but there is a neat trick where you can refer to web.xml context param values from trinidad-config.xml.

You can revert these settings to the optimised values with deployment plans. No need to change this in the source code or build artefact each time. Just set the development optimised versions in your source files so local runs in JDeveloper use the correct values. Then use deployment plans to override these for production and other environments.

This post is part of a series on how to use Selenium automated tests with Oracle ADF.