WDK Automated Test Framework 2.5 Development Guide

EMC® Documentum®
Web Development Kit

Automated Test Framework
Version 2.5
Development Guide
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748‑9103
1‑508‑435‑1000
www.EMC.com
Copyright © 2007 – 2008 EMC Corporation. All rights reserved.
Published August 2008
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS
OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY
DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
For the most up‑to‑date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.
All other trademarks used herein are the property of their respective owners.
Table of Contents
Preface ................................................................................................................................. 7
Chapter 1 Overview ...................................................................................................... 9

Introduction ...................................................................................................... 9
Architecture ...................................................................................................... 9
WDK Automated Test Framework component architecture ............................. 10
Test case configuration file and Java class ....................................................... 11
For more information........................................................................................ 14
Chapter 2 Supporting New Controls ............................................................................ 17

Overview ......................................................................................................... 17
Supporting simple clicks, mouse overs, and value changes .................................. 18
Recording server‑ and client‑side control events ................................................. 20
Control inspection and validation ...................................................................... 21
Modifying the recording inspection page ........................................................... 22
Chapter 3 Enhancing Additional Functionality ............................................................ 29

Overview ......................................................................................................... 29
Responding to WDK Automated Test Framework events .................................... 29
Enhancing default preference restoration ........................................................... 30
Enhancing default object and tree node identification ......................................... 30
Executing code after autologin .......................................................................... 31
Appendix A Implementing Deferred Client Event Processing in Components ................ 33

Overview ......................................................................................................... 33
Procedure ........................................................................................................ 33
Appendix B Interfaces and Abstract Classes .................................................................. 37

Appendix C New Features, Usability Improvements, and Fixed Bugs ............................ 43
Version 2.5 ....................................................................................................... 43
EMC Documentum Web Development Kit Automated Test Framework Version 2.5 Development Guide 3
Table of Contents
List of Figures
Figure 1. Component architecture ........................................................................................ 10

Figure 2. Test case Java class structure .................................................................................. 13
Figure 3. Test case XML configuration file structure .............................................................. 14
4 EMC Documentum Web Development Kit Automated Test Framework Version 2.5 Development Guide
Table of Contents
List of Tables
Table 1. Events that initiate and terminate recording of a test step ........................................ 11
Table 2. Interfaces and abstract classes to implement ........................................................... 37
Table of Contents
Preface
This document describes how to extend the EMC Documentum Web Development Kit Automated
Test Framework.
Intended Audience
The audience of this manual is intended to be developers who want to extend the WDK Automated
Test Framework and who are familiar with WDK.
Revision History
The following changes have been made to this document.
Revision History
Revision Date Description

August 2008 Initial release for version 2.5.
Preface
Chapter 1
Overview
These topics are described:

• Introduction, page 9
• Architecture, page 9
• For more information, page 14
Introduction
The Web Development Kit (WDK) Automated Test Framework helps automate the generation of and
running reusable test cases for WDK applications. You can use the WDK Automated Test Framework
to perform these kinds of tests on WDK applications:
• Sequence of user actions
• Validate actions
• Validate the states of controls
To ensure reusable test cases, the WDK Automated Test Framework does not depend on nor test the
locations of user interface elements on the browser page.
Architecture
The WDK Automated Test Framework consists of a WDK application to record and execute tests
(also known as test cases), and to view the results of the tests. Because the WDK Automated Test
Framework is a WDK application, you can configure and extend it as you would any other WDK
application. For more information, see the Web Development Kit Development Guide.
Overview
WDK Automated Test Framework component

architecture
Figure 1, page 10 shows the components that comprise the WDK Automated Test Framework
application. The testtool component is the main component that contains the components to record
and execute test cases, and view the test results. The testrecorderlauncher component contains the
components to record test cases. The testlauncher component contains the components to execute
test cases. The showtestresult component contains the components to view the results of test case
executions. The unittestcase component displays a message that a component unit test case is being
executed.
Figure 1. Component architecture
You configure the WDK Automated Test Framework by extending (including specifying
custom elements and attributes in) the testframeworkconfig id=ʺdefaultʺ definition in the
testframework_config.xml configuration file in one of these paths:
• For Webtop: webtop/config/test
• For a custom WDK application: webcomponent/config/test
Overview
• For a custom Webtop application: web_application/config/test, where web_application is the web

application virtual root.
Note: If the testframework_config.xml file is not in the web application virtual root directory, then
it is inherited from a parent application layer. Configure the testframework_config.xml file in
which the testframeworkconfig id=ʺdefaultʺ definition was last extended.
To record a test case, you start the test case recorder, specify a WDK application, log in to a content
server repository, and perform the steps that you want to be recorded. Whenever you perform an
action on a control (such as clicking a button or selecting a menu item) or an event occurs (such as
the WDK event, onChangeEvent), that action or event is recorded. Whenever you choose to validate
the state of controls or action results, those states or results are recorded. Because neither mouse
movements, the locations of controls, nor the user interface’s layout and appearance (images, borders,
the size of frames) are recorded, test cases test only the functionality of a WDK application and are
independent of the application’s appearance. All actions, events, and control validation states are
saved to a test case’s Java source classes (*.java) and XML configuration files (*.xml).
To execute a test case, you start the test case launcher and log in to a content server repository. The
WDK Automated Test Framework uses the test case’s Java classes and XML configuration files to run
the test case and display the test results. The WDK Automated Test Framework dynamically generates
JavaScript to simulate user actions, such as clicking controls and mouse overs. Test suites are a group
of test cases; test cases consist of test steps. A test step consists of what is actually recorded between
the events named in Table 1, page 11.
Table 1. Events that initiate and terminate recording of a test step
Events that initiate recording Events that terminate recording
onChangeEvent onFormRenderFinish
onServerEvent onNest
onWebformTagStart onReturn
onReturnJump
onWebformTagStart*
* Only if the body of the webform tag is not processed.
Test case configuration file and Java class

Figure 2, page 13 shows sample Java code that is recorded in a test case. For each test case, a class is
created. Within each test case class, skeleton code for these methods and classes is created:
• setUp, tearDown, and getTestURL public methods
• Inner classes that represent test case steps. Each inner class extends ComponentTestStep and each
inner class name is Stepinteger, where integer is an integer sequentially generated by the recorder.
Overview
Within a test step, user actions are recorded as ClientEvent instances in the array returned by the
getClientEvents method. If the logic to used to create a ClientEvent instance is more than a single line,
then a controlEvent_integer_generate method that returns a ClientEvent instance is created.
If an action to validate is recorded in a test step, the test step class will be created to implement
IActionListener and IActionCompleteListener and skeleton code for these methods are created:
• onPreAction method: Saves the initial state of the action before executing the action.
• onPostAction method: Executes after the action executes.
• onComplete method: Executes after the action completes and calls ITestStepActionValidator,
which calls the default implementation, to validate the action’s initial state with its final state.
The XML configuration code that corresponds to the test case structure is shown in Figure 3, page 14.
Because control state validation is completely controlled through the test case XML configuration file,
no Java code is generated for control state validation.
Overview
Figure 2. Test case Java class structure
Overview
Figure 3, page 14 shows sample XML that is recorded in a test case configuration file. The testcase
element’s id attribute identifies the test case (the id attribute value corresponds to the string entered in
the testcaseid field when recording the test case). The class element contains the name of the test case
Java class. The variables element specifies global variables that the test case uses. The validationdata
element contains teststep elements that specify the control and action results to validate. The global
variables and variables specific to a test step may be set or retrieved by the test case Java class. Each
teststep element’s name attribute corresponds to an inner class that extends ComponentTestStep.
Figure 3. Test case XML configuration file structure
For more information

For an introduction to the Documentum system, see the Content Server 6 Fundamentals.
For information about configuring, customizing, and deploying WDK and WDK applications, see the
Web Development Kit Development Guide.
Overview
For information about using the WDK Automated Test Framework, making reusable test cases, and
creating unit tests, see the Web Development Kit Automated Test Framework User Guide.
Overview
Chapter 2
Supporting New Controls
These topics are included:

• Overview, page 17
• Supporting simple clicks, mouse overs, and value changes, page 18
• Recording server‑ and client‑side control events, page 20
• Control inspection and validation, page 21
• Modifying the recording inspection page, page 22
Overview
To support (also known as instrumentation) new controls in the WDK Automated Test Framework,
you might want to implement these kinds of functionality:
• Recording inspection page: Modifying the recording inspection page to enable inspection of the
new control’s fields.
• Recording server‑ and client‑side control events: Creating XML and Java source code in the test
case configuration file and Java class for server‑ and client‑side control events.
• Control validation: Validating control states.
• Control inspection: Inspecting and setting control state during test case recording.
When you do not provide support for a new control, test recording outputs comments in the test case
about an unknown control.
Supporting simple clicks, mouse overs, and

value changes
If the control event that you want to support is a simple click, mouse over, or value change (of the
control), then extend the ClientEvent class, implement the following interfaces, and specify your
extended classes in your extended testframework_config.xml file:
• ISetValueEventGenerator: You implement this interface when you want to record the change
in the value of the control.
• IClickEventGenerator: You implement this interface when you want to record a click on the control.
• IMouseOverEventGenerator: You implement this interface when you want to record a mouse
over action on the control.
To register your extended ClientEvent classes with the WDK Automated Test Framework, add these
XML structures in your extended testframework_config.xml file:
1 <setvalueeventgenerators>
<class>com.documentum.web.test.controlevent.dmf.MySetValueEvent</class
</setvalueeventgenerators>
2 <clickeventgenerators>
<class>com.documentum.web.test.controlevent.dmf.MyClickEvent</class>
</clickeventgenerators>
3 <mouseovereventgenerators>
<class>com.documentum.web.test.controlevent.dmf.MyMouseOverEvent</class>
</mouseovereventgenerators>
1 Specify the fully qualified name of your class that implements ISetValueEventGenerator.
2 Specify the fully qualified name of your class that implements IClickEventGenerator.
3 Specify the fully qualified name of your class that implements IMouseOverEventGenerator.
Example 21. Supporting clicks

For example, if you create a new control, called MyControl, that responds to a click, then
you extend the ClientEvent class in a class, called MyControlClickEvent, and implement the
IClickEventGenerator’s two methods, generateEvent and isApplicable:
public boolean isApplicable(Control control)
{
1 return (control instanceof MyControl);
}
...
public ClientEvent generateEvent(Control control)

{
2 return new MyControlClickEvent((MyControl)control);
}
1 Return true if the control is an instance of the MyControl class or false if not.
2 Return a MyControlClickEvent instance for the control.
For ClientEvent, override the getJavaScript method. You can either code the JavaScript to be used
in this method or you can call other common classes to build the JavaScript. In this example, the
getJavaScript method calls the ControlById and MyControlClickEvent common classes to build the
JavaScript.
public String getJavaScript()
{
String controlId = m_myControl.getId();
1 IControlVar controlVar = new ControlById(controlId);
2 return new MyControlClickEvent(controlVar).getJavaScript();
}
1 Retrieves a reference to an IControlVar instance that is used to create a myControlClickEvent

instance.
2 Returns the JavaScript using the getJavaScript method on the MyControlClickEvent.
In the MyControlClickEvent class, the getJavaScript method calls the getDeclareScript method on the
ControlById instance (m_controlVar) to retrieve the JavaScript, and adds browser‑specific JavaScript
(depending on whether the browser is Internet Explorer or not):
public String getJavaScript()
{
StringBuffer buf = new StringBuffer();
1buf.append(m_controlVar.getDeclareScript());
if (ClientInfoService.getInfo().isBrowser(ClientInfo.MSIE))
{
buf.append(m_controlVar.getName() + ".click();\n");
}
else
{
buf.append("var eventClick = document.createEvent(\"MouseEvents\");");
buf.append("eventClick.initEvent(\"click\",true,true);");
buf.append(m_controlVar.getName() + ".dispatchEvent(eventClick);");
}
return buf.toString();
}
1 Calls the getDeclareScript method on the ControlById instance (m_controlVar) to retrieve the
JavaScript.
The ControlById getDeclareScript method returns this JavaScript, which instantiates a variable that
references a control passed to ControlById:
public final String getDeclareScript()
{
StringBuffer buf = new StringBuffer();
1buf.append("var controlId = ’" + m_id + "’;\n");
2if (m_frame == null)

{
3buf.append("var " + getName() + " = document.getElementById(controlId);\n");
}
else
{
buf.append("var " + getName() + " = null;\n");
buf.append("var frameName = ’" + m_frame + "’;\n");

buf.append("var strFramePath = getAbsoluteFramePath(frameName);\n");
buf.append("if (strFramePath == null)\n");
buf.append("{\n");
buf.append(" wdkTestAutomationJavascriptErrorHandler(’fail to retrieve path for frame ’ +
frameName, window.location, ’???’);\n");
buf.append("}\n");
buf.append("else\n");
buf.append("{\n");
buf.append(" strFramePath = walkDownFrameSet(strFramePath);\n");
buf.append(" var targetFrame = eval(strFramePath);\n");
buf.append(" if (targetFrame) " + getName() + " = targetFrame.document.getElementById(
controlId);\n");
buf.append(" else\n");
buf.append(" {\n");
buf.append(" wdkTestAutomationJavascriptErrorHandler(
’fail to retrieve frame from path ’ + strFramePath, window.location, ’???’);\n")
buf.append(" }\n");
buf.append("}\n");
}
buf.append("if (!" + getName() + ") wdkTestAutomationJavascriptErrorHandler(

’Failed to retrieve control ’ + controlId, window.location, ’???’);\n");
return buf.toString();
}
1 Inserts the JavaScript to set a variable; the m_id variable is the control’s ID.
2 Determines whether the frame’s name has been passed into this class. In this case, the frame’s
name is not passed in.
3 Inserts the JavaScript that sets the control name variable to a DOM document object’s element
identified by the control’s ID. The class’s getName() method generates a unique control name.
Recording server and clientside control

events
If the control has multiple clickable parts, you extend the ClientEvent class and implement these
interfaces in the extended class (instead of IClickEventGenerator, IMouseOverEventGenerator, or
ISetValueEventGenerator for simple clicks, mouse overs, and value changes):
• com.documentum.web.test.recorder.IClientUserEventProducer: You implement this interface to

provide client‑side event recording for controls.
Note:
— A client‑side control is a control in which its runatclient attribute is set to true.
— You do not need to implement this interface, if the control is supported by a class that
implements IClickEventGenerator, IMouseOverEventGenerator, or ISetValueEventGenerator.
• com.documentum.web.test.recorder.IControlEventProducer: You implement this interface to
provide server‑side event recording for controls.
Note: You do not need to implement this interface, if the control is supported by a class that
implements IClickEventGenerator, IMouseOverEventGenerator or ISetValueEventGenerator.
• com.documentum.web.test.recorder.IClientUserEventCreator: You implement this interface to
provide client‑side event recording for controls in which the resulting client‑side actions require
more feedback than returning only the control that was affected by the user action. For example,
the tree control uses this interface to return the node in the tree control that was clicked. To return
only the tree control when a node is clicked is not granular enough information.
• com.documentum.web.test.clientevent.ClientEvent: You derive a class from this abstract class and
implement the method that provides the JavaScript code that simulates the client event.
To register your extended ClientEvent classes with the WDK Automated Test Framework, add these
XML structures in your extended testframework_config.xml file:
1 <controleventproducers>
<class>com.documentum.web.test.controlevent.UnnamedControlEvent</class>
</controleventproducers>
2 <clientusereventproducers>
<class>com.documentum.web.test.recorder.ClientSideControlEventProducer</class>
</clientusereventproducers>
3 <clientusereventcreators>
<class>com.documentum.web.test.recorder.TreeNodeUserEvent</class>
</clientusereventcreators>
1 Specify the fully qualified name of your class that implements IControlEventProducer.
2 Specify the fully qualified name of your class that implements IClientUserEventProducer.
3 Specify the fully qualified name of your class that implements IClientUserEventCreator.
Control inspection and validation

You only need to implement inspection and validation for new controls when the current inspection
or validation default behavior does not meet your control’s requirements. You usually only need
to enable your control’s attributes to be displayed on the inspection page of the test recorder.
Occasionally, you might need to implement the creation of validation XML, the parsing of the
validation XML, and the performance of the validation itself. By default, validation is performed
by the DefaultUIValidator class and the inspector component enables you to specify the control’s
attributes in the inspector_component.xml file’s <commomcontrolvalidation> element for validation.
To implement validation for a control:

1. Modify the recording inspection page.
See Modifying the recording inspection page, page 22.
2. (Optional) The Inspector component’s default implementation is usually sufficiently general
enough to create the validation XML for any new controls. Otherwise, you can create your own
inspection component that calls your own implementation of ITestStepUIValidationProducer. The
validation XML generated by your implementation of ITestStepUIValidationProducer must be
able to be parsed by an implementation of ITestStepUIValidator.
Note: A private inner class of the Inspector component behavior class (com.documentum.web.
test.validation.ui.inspector.Inspector) implements ITestStepUIValidationProducer and uses
UIValidationProducerHelper to create the validation XML.
3. (Optional) DefaultUIValidator is the default implementation of ITestStepUIValidator and is
usually sufficiently general enough to parse the validation XML and perform validation of any
new controls. Otherwise, you can code your own implementation of ITestStepUIValidator. Your
implementation must be able to parse the validation XML generated by your implementation
of ITestStepUIValidationProducer.
DefaultUIValidator attempts to resolve a control by container and name or, if it is in a datagrid,
by the row in the datagrid identified by the arguments of the row. When a unique control is
found, then its fields are validated against the specific values specified in the test case. If a unique
control is not found, the validator fails the test case. The ITestStepUIValidator implementation
to call for an action is specified in the teststepactionvalidators/entry element in your extended
testframework_config.xml file.
Modifying the recording inspection page

To modify the recording inspection page, you extend the Inspector component and extend or
implement some or all of these interfaces and abstract classes:
• InputAssistance
• InputAssistanceInspector
• UIValidationFieldHandler
To display your control’s states on the inspection page of the test recorder:
1. Create a class that extends UIValidationFieldHandler and override the getInputAssistance and
getValue methods. The getInputAssistance method returns a specific InputAssistance instance for
a getterclass field specified in your extended testframework_config.xml file. The getValue method
retrieves the value of a control’s attribute. An InputAssistance instance (for example, an EditBox or
RadioGroup control) indicates that a field is to be inspected.
For example, DropDownListFieldHandler extends UIValidationFieldHandler. The options and
value in the getValue and getInputAssistance methods are mapped to the options and value fields
in the testconfig_component.xml file shown in Step 3.
public String getValue(Control control, String field, ArgumentList parameterList)
{
if (control instanceof DropDownList)
{
DropDownList thisDropDownList = (DropDownList) control;
1if (field.equals("value"))
{
for (Object o : thisDropDownList.getOptions())
{
Option thisOption = (Option)o;
if (thisOption.getValue().equals(thisDropDownList.getValue()))
{
return thisOption.getValue();
}
}
}
2if (field.equals("options"))
{
String options = "";
{
options += ((Option)o).getLabel() + ",";
}
return options.substring(0, options.length() 1);
}
}
return null;
}
public InputAssistance getInputAssistance(Control control, String field,

ArgumentList parameterList)
{
3if (field.equals("value"))
{
Dropdown dropdownIA = new Dropdown();
DropDownList thisDropDownList = (DropDownList) control;
{
Option thisOption = (Option)o;
dropdownIA.addChoice(thisOption.getLabel(), thisOption.getValue());
}
return dropdownIA;
}
else
{
return new Editbox();
}
}
1 Checks whether the field is the DropDownList control’s value attribute or not and if it is the value
attribute, then returns the current value of the value attribute of the thisDropDownList.
2 Checks whether the field is the options attribute or not and if it is the options attribute, then
retrieves the labels.
3 Checks whether the field is the value attribute or not and if it is the value attribute, then a dropdown
list instance, thisDropDownList, is populated by a list of values and labels is returned; otherwise,
an editbox is returned.
2. Extend the Inspector component (app\wdk\config\test\inspector_component.xml file) and
add this XML structure to your extended Inspector component’s configuration file in the
config/scope/component/controls element:
1 <control>
2 <class>control_class_name</class>
3<producer>validation_xml_producer_class_name</producer>
4<validation>
<entry>
<reference>element_config</reference>
</entry>
...
<entry>
<field>control_attribute</field>
</entry>
...
<identity>
<entry>
<field>identity_element</field>
</entry>
...
</identity>
...
</control>
1 This element contains the structure that specifies how to inspect a particular control.
2 This element specifies the package name and name of the class that implements the control.
3 This element specifies the name of the class that creates the validation XML.
4 Specify element structures that contain fields that you want to validate. An <entry> element can
contain a <reference> element that refers to an element in this configuration file or a <field> element
that specifies a control attribute to validate.
For example, this XML structure provides inspection for the DropDownList control:
<control>
<class>com.documentum.web.form.control.DropDownList</class>
<validation>
<entry>
<reference>commomcontrolvalidation</reference>
</entry>
<entry>
<reference>valuevalidation</reference>
</entry>
<entry>
<reference>dropdownlistvalidation</reference>
</entry>
</validation>
<identity>
<entry>
<reference>commomcontrolidentity</reference>
</entry>
</identity>
</control>
3. Extend the appropriate testframework_config.xml file and add this XML structure to your
extended testframework_config.xml file in the config/scope/component/controls element, where
the <field> elements in <fieldgetters> correspond to the fields in the <field> elements specified in:
1 <control>
2<class>control_class_name</class>
3<definitioncomponent>component_name</definitioncomponent>
4<fieldgetters>
5<field name="name" getterclass="class_name" />
...
<field name="name" getter="attribute" />
...
</fieldgetters>
6<validator>validator_class_name</validator>
</control>
1 Contains the structure that specifies how to perform user interface validation on a particular control.
2 Specifies the package name and name of the class that implements the control. This value must
be the same as the control_class_name in Step 2.
3 Specifies the name of the component in which to define the validation. The default is the inspector
component, which is usually sufficient.
4 Contains the structure that specifies attributes in the control.
5 Specifies the name (in the name attribute) of a field and either:
• getterclass attribute that specifies the package name and the name of the class that extends
UIValidationFieldHandler
• getter attribute that specifies the name of a method in the control_class_name.
6 Specifies the name of the class that creates the validation XML.
For example, this XML provides validation for the DropDownList control:
<control>
<class>com.documentum.web.form.control.DropDownList</class>
<fieldgetters>
<field name="value" getterclass="com.documentum.web.test.validation.ui.
fieldhandler.DropDownListFieldHandler" />
<field name="size" getter="getSize" />
<field name="width" getter="getWidth" />
<field name="height" getter="getHeight" />
<field name="options" getterclass="com.documentum.web.test.validation.ui.
fieldhandler.DropDownListFieldHandler" />
</fieldgetters>
</control>
4. (Optional) To change the recording inspection page for new controls, you extend
com.documentum.web.test.validation.ui.inputassistance.InputAssistance and
com.documentum.web.test.validation.ui.inspector.InputAssistanceInspector. When extending
InputAssistanceInspector, initialize the controls that are to be used in the corresponding JSP
layout, and save the information to validate according to the controls’ states. For example, for a
dropdown control, you extend InputAssistance and implement methods to create a name‑value
pair that represents a choice in the dropdown, add a choice, get all the available choices, and
get the label and value of a choice:
package com.documentum.web.test.validation.ui.inputassistance;
import java.util.List;
import java.util.ArrayList;
public class Dropdown extends InputAssistance

{
public Dropdown()
{
}
1 public static class Choice

{
private Choice(String label, String value)
{
m_label = label;
m_value = value;
}
public String getLabel()

{
return m_label;
}
public String getValue()

{
return m_value;
}
private String m_label = null;

private String m_value = null;
}
2 public void addChoice(String label)

{
Choice choice = new Choice(label, label);
m_choices.add(choice);
}
public void addChoice(String label, String value)

{
Choice choice = new Choice(label, value);
m_choices.add(choice);
}
3 public List<Choice> getChoices()

{
return (List<Choice>) (m_choices.clone());

}
4 private ArrayList<Choice> m_choices = new ArrayList<Choice>();

}
1 Nested class that represents a name‑value pair for the choice in the dropdown.
2 Adds a choice with a label or both a label and value to the dropdown.
3 Retrieves all of the available choices.
4 An array, m_choices, of all the choices.
In this element structure in your extended inspector_component.xml, specify the

InputAssistance‑derived class, the InputAssistanceInspector‑derived class, and the JSP fragment
to display in the inspection page:
<definition>
<inspector>
<inputassistanceclass>com.documentum.web.test.validation.ui.inputassistance.Dropdown
</inputassistanceclass>
<class>com.documentum.web.test.validation.ui.inspector.DropdownInspector</class>
<jsp>/wdk/system/test/inputassistance/dropdownInputAssistance.jsp</jsp>
</inspector>
...
</definition>
Chapter 3
Enhancing Additional Functionality

• Responding to WDK Automated Test Framework events, page 29
• Enhancing default preference restoration, page 30
• Enhancing default object and tree node identification, page 30
• Executing code after autologin, page 31
Overview
You can enhance additional WDK Automated Test Framework functionality in these areas:
• Responding to WDK Automated Test Framework events, page 29
• Enhancing default preference restoration, page 30
• Enhancing default object and tree node identification, page 30
• Executing code after autologin, page 31
Responding to WDK Automated Test

Framework events
To implement responding to WDK Automated Test Framework events, implement this interface:
• ITestHarnessEventListener: Provides functionality to respond to starting up and shutting down
the Automated Test Framework lifecycle events. Add your implementation to the eventlisteners
element in your extended testframework_config.xml file.
Note: To create your own logging facility for test cases, implement this interface in addition
to the TestResult.IListener.
Enhancing default preference restoration

To ensure that test cases and test suites start in a clean state, the WDK Automated Test Framework
uses the PreferenceRestorer.ICustomHandler and PreferenceRestorer.IListener interfaces to restore
user preferences (for example from the documentum theme back to summer theme) and temporary
and permanent internal system settings (for example, the path that a user navigated within the current
session) to the ones that were set before the test case or test suite execution started.
To implement restoring user preferences in addition to the ones restored by PreferencesRestorer,
implement these interfaces:
• PreferenceRestorer.ICustomHandler: Provides functionality that listens for testcase and testsuite
events and restores the user preferences to the ones that were set before the testcase execution
started.
• PreferenceRestorer.IListener: Provides functionality that listens for testcase and testsuite events
and restores the temporary and permanent internal system settings to the ones that were set
before the testcase execution started.
PreferencesRestorer, as used by the TestCaseDriver, listens to test case and test suite lifecycle events. It
stores all preferences in the application server machine’s cookie JAR file and temporary preferences
prior to a test case or test suite setup, and restores them after test case or test suite teardown.
The PreferencesRestorer.IListener interface enables restoring preferences in addition to the ones
restored by PreferencesRestorer. Register your implementation to the preferences restorer using the
PreferencesRestorer.registerListener method. The restore() method, called at a test case or test suite
teardown, restores the preferences, which ensures that the test case or test suite starts in a clean
state. The restoreTemporary() method, called when a FormAction is invoked, ensures that the action
starts in a clean state.
Enhancing default object and tree node

identification
To enhance identifying objects, implement this interface:
• IIdIdentifierFunctionProvider
The default implementation uses object attributes as parameters. An example of another
implementation would be for a dm_sysobject object. Because a dm_sysobject object is best identified
in part by its location in the repository, one of the parameters would be a repository path to the
dm_sysobject object. You specify your implementation in the ididentifierfunctionproviders element of
your extended testframework_config.xml file.
To enhance identifying tree nodes, implement this interface:
• ITreeNodeIdentifierFunctionProvider
The default implementation uses the object ID of the tree nodes instance as a parameter. An
example of another implementation would be one that identifies nodes in a VDM tree. You
specify your implementation in the treenodeidentifierfunctionproviders element of your extended
testframework_config.xml file.
Executing code after autologin

When the autologin feature is used, the login component is bypassed. However, in some cases, the
login component actually performs initialization that is not related to the login component; for
example, setting session state or the state of singleton instances.
To execute code after completing autologin:

1. Create a class that implements the IPostAutoLoginListener interface.
You implement the onPostLoginListener() method, which is called after the test framework
bootstrap service has completed the autologin, to execute your desired behavior.
2. Add this element to the testframework_config.xml in the relevant application layer:
<postautologinlisteners>
<class>class_name</class>
</postautologinlisteners>
Where class_name is the complete class name of the class that implements the IPostAutoLoginListener
interface.
Appendix A
Implementing Deferred Client Event
Processing in Components

• Procedure, page 33
Overview
When you create a component that includes client events that are not fired immediately after the
DOM is ready, you must call WDK ATF JavaScript methods in the component’s JSP to record, as
DeferredClientEvent objects, all events to defer while the component is performing other processing .
During test execution, the DeferredClientEvent objects are not executed until after the corresponding
processing has completed.
For example, even after results are displayed in the search component, the component continues to
poll the content server for additional search results. So, if a client event is executed before the polling
has completed, the client event can fail when it attempts to acquire the posting lock (which is most
likely owned by the polling call).
Procedure
1. Call the window.suspendTestEvents function before starting your deferred events and the
window.resumeTestEvents function after the deferred events have completed as shown in this
example from webcomponent\library\searchresultslist\search60\searchresults.jsp.
The <dmf:webform/> tag, which is specified in all component JSPs, includes the
suspendTestEvents() and resumeTestEvents() functions.
The initInlineCall() function is called from within the body of the searchresults.jsp file and is the
initial starting point for polling for search updates from the content server.
Implementing Deferred Client Event Processing in Components
<script type="text/javascript">
var updateStatusCall;
function initInlineCall ()
{
1 notifyPollingInitiation()
2 updateStatusCall = setInterval("updateSearchStatus()", 1000);
}
function updateSearchStatus ()
{
var prefs = InlineRequestEngine.getPreferences(InlineRequestType.JSON);
3 prefs.setCallback(renderSearchStatus);
postInlineServerEvent(null, prefs, null, null, "onUpdateSearchStatus",
null, null);
function renderSearchStatus (data)

{
var showResults = data[’<%=Search60.JSON_SHOW_RESULTS%>’];
var isCompleted = data[’<%=Search60.JSON_IS_COMPLETED%>’];
if (showResults)
{
...
}
else
{
if (isCompleted)
{
...
}
else
{
...
}
...
}
unlock();
if (isCompleted)
{
4 notifyPollingComplete();
}
}
function notifyPollingInitiation()
{
if (window.suspendTestEvents)
{
5 window.suspendTestEvents();
}
}
function notifyPollingComplete()
{
if (window.resumeTestEvents)
{
6 window.resumeTestEvents();
}
}
function showSearchResults ()
{
clearInterval(updateStatusCall);
unlock();
notifyPollingComplete();
<dmf:postserverevent handlermethod=’onShowResults’/>
}
function onStopSearch ()
{
unlock();
<dmf:postserverevent handlermethod=’onStopSearch’/>
}
function onRestartSearch ()
{
unlock();
<dmf:postserverevent handlermethod=’onRestartSearch’ />
}
function unlock ()
{
if (isEventPostingLocked())
{
releaseEventPostingLock();
}
}
</script>
1 This line calls a function that invokes the suspendTestEvents() function.

2 This line calls the updateSearchStatus() function.
3 This line calls the renderSearchStatus() function.
4 This line calls a function that invokes the resumeTestEvents() function.
5 You call this function every time you need to suspend normal event recording. This function pauses
recording until resumeTestEvents() is called. During test execution (since this path gets executed both
during recording and playback), this function causes the WDK ATF to stop consuming steps.
6 You call this function every time that you need to resume normal event recording (for example from
the onStopSearch() onRestartSearch functions). During recording, this function restarts recording and
records, as deferred client events, anything from this point on until a form refresh occurs. During
playback, this function causes the WDK ATF to resume consuming steps and fire the deferred events
for the step.
Appendix B
Interfaces and Abstract Classes
Table 2, page 37 lists the interfaces you can implement and abstract classes you can extend to enhance
the functionality of the WDK Automated Test Framework.
Table 2. Interfaces and abstract classes to implement
Package Interfaces/Abstract Classes Description

com.documentum.web.test ComponentTestCase (Abstract class) Provides
functionality for test cases.
ComponentTestCase. Enables listening for client
IClientEventGetListener events from components
and implementing pre‑ and
post‑event methods based on
the component.
ComponentTestStep (Abstract class) Enables test
step in a test case.
ComponentUnitTestCase (Abstract class) Enables unit
testing components.
FormTestCase (Abstract class) Enables test
cases for forms.
FormTestCase.ClientEventLis‑ Enables listening for client
tener events from forms and
implementing pre‑ and
post‑event methods based on
the form.
FormTestStep (abstract class) Enables test step in a test case
for a form.
IIdIdentifierFunctionProvider Enables identifying an object
by any associated data. An

implementation of this interface
would:
• Given the object ID, return
the parameters that uniquely
identify the object.
• Given the parameters, return
the object ID.
ITestHarnessEventListener Provides functionality to
respond to starting up and
shutting down the WDK
Automated Test Framework.
ITreeNodeIdentifierFunction‑ Enables identifying tree nodes
Provider for different kinds of trees. An
implementation of this interface
would:
• Given the tree node instance,
return the parameters that
uniquely identify the tree
node.
• Given the parameters, return
the tree node instance.
PreferenceRestorer. Enables restoring static user
ICustomHandler preferences (that is, from
one predefined value to
another); for example, from the
documentum theme back to the
summer theme.
PreferenceRestorer.IListener Provides functionality that
listens for test case and test
suite events and restores
temporary and permanent
internal system settings.
TestResult.IListener Enables listening for test case
execution status: error, failure,
pending, success, execution
queue cleared, pending status
removed.

com.documentum.web.test. ClientEvent (Abstract class) Enables
clientevent responding to a client event
and implementing retrieving
the JavaScript code that
simulates the client event.
com.documentum.web.test. IControlVar The interface IControlVar is
controlevent used to represent a JavaScript
variable that holds a reference
to an HTML control.
com.documentum.web.test. IClickEventGenerator Enables generating click event
controlevent.dmf for controls.
IMouseOverEventGenerator Enables generating mouse over
event for controls.
ISetValueEventGenerator Enables generating set value
event for controls.
com.documentum.web.test. IClientUserEventCreator Factory interface to create
recorder instances of ClientUserEvent.
IControlEventProducer Enables creating XML and Java
code for control events.
IClientUserEventProducer Enables creating XML and Java
code for client‑side (where
runatclient=”true”) control
events.
ITestStepActionValidationPro‑ Creates the default validation
ducer configuration for a test step
that invokes an action.
Default implementation is
DefaultValidationProducer.
ITestStepActionValidator Enables action validation logic.
AbstractValidationProducer (Abstract class) Enables
creating configuration element
structure for validation.
com.documentum.web.test. ITestStepUIValidationProducer Enables creating XML to
validation.ui validate control state.
ITestStepUIValidator Enables validating control state.

com.documentum.web.test. IUIValidationFieldHandler Enables creating a logical field
validation.ui.fieldhandler associated with a control field.
An implementation of this
interface returns specific values
according to the control or
other controls related to the
specified control.
DatagridColumnFieldHandler Retrieves metadata object
specified in a column
description list (both visible
and hidden columns).
UIValidationFieldHandler This class provides an
implementation of the
normalizeParameterValue
method that passes the value.
Field Handlers should extend
from this class.
com.documentum.web.test. ColumnSelector (Abstract class) Enables adding
validation.ui.inputassistance choices to and retrieving
available choices for a column’s
input assistance to be displayed
in the validation user interface.
com.documentum.web.test. IInputAssistanceContainer Enables creating unique control
validation.ui.inspector names for a component.
IValidationManager Enables adding and removing
validation entries.
IValidationManager. Enables retrieving parameters
IValidationEntry and their associated values
from a validation entry.
InputAssistanceInspector (Abstract class) Used by
the Inspector component to
support the inspection of fields

that use a particular kind of
InputAssistance.
Appendix C
New Features, Usability Improvements,
and Fixed Bugs
See the WDK Automated Test Framework User Guide for a list of new features, usability improvements,
and fixed bugs that apply to using the WDK Automated Test Framework.
Version 2.5
Support client events that are deferred; that is, client events that are not fired immediately after the
DOM is ready. For example, even after results are displayed in the search component, the component
continues to poll the server for additional search results. So, if a client event is executed before the
polling has completed, the client event can fail when it attempts to acquire the posting lock (which
is most likely owned by the polling call). Therefore, to support deferred client events, JavaScript
in the component JSP instructs the test recorder to record any events that occur during polling as
DeferredClientEvent objects. During test execution, polling is executed and the DeferredClientEvent
objects are not executed until after polling has completed. Deferred client events are part of new
WDK AJAX‑related functionality. (New feature)
New Features, Usability Improvements, and Fixed Bugs
Index
A I
architecture IClientUserEventCreator
component, 10 introduction, 21
introduction, 9 IClientUserEventProducer
introduction, 21
IControlEventProducer
C introduction, 21
click events introduction
example of supporting, 18 WDK Automated Test Framework, 9
ClientEvent
introduction, 21
components J
showtestresult, 10 Java classes
testlauncher, 10 test cases, 11
testrecorderlauncher, 10
testtool, 10
unittest, 10
O
WDK Automated Test Framework, objects
in, 10 identification, 30
configuration
test case files, 11, 14 P
testframework_config.xml, 10 preference restoration
WDK Automated Test Framework, 10 enhancing, 30
controls
click events, 18
events, 18 R
events, server‑, client‑side, 20 recording
inspection, 21 ClientEvent, 21
mouse over events, 18 control events, 20
recording inspection page, 22 IClientUserEventCreator, 21
supporting new, overview, 17 IClientUserEventProducer, 21
validation, 21 IControlEventProducer, 21
value change events, 18 inspection page, modifying, 22
E S
events showtestresult component
controls, 18 description, 10
test step initiation, 11
test step termination, 11
WDK Automated Test Framework, 29
Index
T description, 10
test cases testrecorderlauncher component
configuration files, 14 description, 10
Java classes, 11 to 12 testtool component
test steps description, 10
definiton, 11 tree nodes
description, 11 identification, 30
test suites
definition, 11 U
testframework_config.xml unittest component
description, 10 description, 10
testlauncher component

WDK Automated Test Framework 2.5 Development Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WDK Automated Test Framework 2.5 Development Guide

Uploaded by

Copyright:

Available Formats

EMC® Documentum®

Web Development Kit

Chapter 1 Overview ...................................................................................................... 9

Chapter 2 Supporting New Controls ............................................................................ 17

Chapter 3 Enhancing Additional Functionality ............................................................ 29

Appendix A Implementing Deferred Client Event Processing in Components ................ 33

Appendix B Interfaces and Abstract Classes .................................................................. 37

Figure 1. Component architecture ........................................................................................ 10

Revision Date Description

These topics are described:

WDK Automated Test Framework component

Figure 1. Component architecture

• For a custom Webtop application: web_application/config/test, where web_application is the web

Table 1. Events that initiate and terminate recording of a test step

Events that initiate recording Events that terminate recording

Test case conﬁguration ﬁle and Java class

Figure 2. Test case Java class structure

Figure 3. Test case XML conﬁguration ﬁle structure

For more information

These topics are included:

Supporting simple clicks, mouse overs, and

Example 2­1. Supporting clicks

public ClientEvent generateEvent(Control control)

1 Retrieves a reference to an IControlVar instance that is used to create a myControlClickEvent

2if (m_frame == null)

buf.append("var frameName = ’" + m_frame + "’;\n");

buf.append("if (!" + getName() + ") wdkTestAutomationJavascriptErrorHandler(

Recording server­ and client­side control

• com.documentum.web.test.recorder.IClientUserEventProducer: You implement this interface to

Control inspection and validation

To implement validation for a control:

Modifying the recording inspection page

public InputAssistance getInputAssistance(Control control, String field,

public class Dropdown extends InputAssistance

1 public static class Choice

public String getLabel()

public String getValue()

private String m_label = null;

2 public void addChoice(String label)

public void addChoice(String label, String value)

3 public List<Choice> getChoices()

return (List<Choice>) (m_choices.clone());

4 private ArrayList<Choice> m_choices = new ArrayList<Choice>();

In this element structure in your extended inspector_component.xml, specify the

These topics are included:

Responding to WDK Automated Test

Enhancing default preference restoration

Enhancing default object and tree node

Executing code after autologin

To execute code after completing autologin:

These topics are included:

function renderSearchStatus (data)

1 This line calls a function that invokes the suspendTestEvents() function.

Table 2. Interfaces and abstract classes to implement

Package Interfaces/Abstract Classes Description

Package Interfaces/Abstract Classes Description

Package Interfaces/Abstract Classes Description

Package Interfaces/Abstract Classes Description

Package Interfaces/Abstract Classes Description

You might also like

Example 21. Supporting clicks

Recording server and clientside control