Skip to main content

What you may need to know about flag ?

You can use in web.xml file to enable automation testing.

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


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).  


Correct usage



Great article, where is the testing information dumped? is it at the server log file or just at the log console?
Jobinesh said…
Juan, this parameter actually sets up the basic infrastructure for enabling the automation. Later on, testing framework like Selenium can be used to do the actual job.
Baig said…
You are great.

My problem was BINGO to Your No.2 :)

Jobinesh said…
I'm glad I was able to help :)
Oracle ADF Online Training - Click Here For Enquiry -
Introduction to Fusion and ADF - Exploring Jdeveloper - Database Schema Design - Data Modeling with ADF Business Components - Entity Objects and Associations - View Objects and View Links - Application Modules - Programmatically Modifying Default Behavior - Business Validation - Introduction to User Interface Technologies - Understanding ADF Data bindings - Understanding ADF Task Flows - Enriching the Page Content - Understanding Layout Basics - Ensuring Reusability - Implementing Page Navigation - Handling Application Events - Managing and Validating Data - Transaction Management - Troubleshooting ADF Applications - Deploying ADF Applications (Web Logic)

Popular posts from this blog

How to set Bind Variable Values at runtime ?

In this post I'm sharing a couple of approaches for programmatically setting bind variables values at run time. This post is an attempt to explain 'When to use what ?'[ In case if you are familiar with 'Bind Variables' in ADF BC, please refer Section 5.10, Working with Bind Variables in Fusion Developer's Guide ]

1. Set the Bind Variable value using RowSet::setNamedWhereClauseParam(...)

You can use use the setNamedWhereClauseParam(...) method on the ViewObject interface (which extends oracle.jbo.RowSet) to set the value for bind variables. Please note this sets the value on default RowSet. In other words, this doesn't have any effect on the secondary RowSets that you/system generates.
ViewObject vo = am.findViewObject("EmployeesView1"); vo.setNamedWhereClauseParam("bindVarDeptId", new Number(10)); vo.executeQuery();
2. Set the Bind Variable value using ViewObject's VariableValueManager::setVariableValue(...)

VariableValueManager Ma…

Happy New Year 2018 !

We can't go back and change the beginning, but we always can start where we are and change the ending. Believe in yourself and you will be unstoppable!

Wishing you and your family a very happy new year 2018 !!!