What you may need to know about oracle.adf.view.rich.automation.ENABLED flag ?

You can use oracle.adf.view.rich.automation.ENABLED in web.xml file to enable automation testing.

<context-param>
      <param-name>oracle.adf.view.rich.automation.ENABLED</param-name>
      <param-value>true</param-value>
</context-param>

But you may need to be measured while setting this parameter and it's advised to keep this parameter disabled in production environment.

Why?

Because enabling the test automation parameter generates a client component for every component on the page which can negatively impact performance.
1. Result in increased page size
2. Involves in 'n' number of checks(assertions) at run time.

Now, let me share a couple of interesting observations related to this parameter.

Few teams reported saying that after enabling this parameter, some web pages started misbehaving. Most of the issues were related to popup dialog, like popup (Custom popup, List Of Value, Datepicker etc) dialog no longer respond to user actions, started throwing assertion failed errors "Incorrect use of AdfRichUIPeer.GetDomNodeForCommentComponent.AdfRichPopup" etc.

Hey...So Is this parameter that bad ? No :)

All these issues were caused by wrong code. Enabling 'automation' actually brought them to light. Enabling 'automation' in turn enables Assertion, so the system throws assertion failed errors whenever it encounters incorrect usage of components. Root cause for this error is invalid DOM tree on the client side. Current implementation doesn't communicate the exact cause while throwing assertion error, but this is getting arrested in next release.

Coding Errors

Listing some of the coding errors that caused the wrong view/page behavior when automation is enabled(shared by different teams).

1. Missing Iterator binding : Some controls were referring iterators which were missing from the page definition. If the assertion is not enabled, this error is silent and simply caused the component referring the missing iterator not to render.

2. Keeping non-rendered(rendered=false) components as partial trigger component. Work around is to use visible=false.
For example,the following jsf snippet causes Assertion failure error "Assertion failed: Incorrect use of AdfRichUIPeer....", because of the above stated reason.

<af:commandButton  id="hiddenBtn" rendered="false" text="Test"/>
<af:table var="row" id="t1"  partialTriggers="::hiddenBtn">

3. Improper nesting of tags.
For example...

The below hierarchy is wrong. Because Rich Client
events will bubble up to component handlers, 
so listeners should be enclosed properly within
the source component that originated the event
(Thanks to Gary Van Matre for explaining this behavior).  

<af:commandLink 
    <af:showPopupBehavior
        <af:image
        <af:clientListener 

Correct usage

<af:commandLink 
    <af:image
       <af:showPopupBehavior
       <af:clientListener