This functionality is supported only if you are using the Classic Agent.
Consider these criteria when deciding whether to record classes for Java objects. When you record classes,
Silk Test Classic derives tags from the Java class name. You may also find it helpful to consult the decision tree for dealing with custom Java classes.
Am I testing only predefined Java classes?
If you are testing only predefined Java classes, then you do not need to record additional classes. Check the list of predefined Java classes to be sure. If you want to access native methods for predefined Java classes, then you must remove the existing definition and re-record the class.
Am I testing visible custom controls?
If you are testing custom Java controls that are not predefined, then you must record classes for these controls. In this case, the custom controls are visible, but display as
CustomWin objects. After you record the class, you can retrieve information about any number of instances (objects) of that class.
Do I want to test custom controls that are currently ignored?
To maintain efficiency during the recording process,
Silk Test Classic ignores custom Java controls that are not considered relevant for testing, such as containers or panels. Ignored objects are not recognized at all by
Silk Test Classic, not even as
CustomWin objects.
Even so, you can expose and record classes for ignored Java objects in standalone Java applications or in Java applets that you consider important for testing purposes.
Have I modified an existing class definition?
If you add, delete, or modify any native methods or parameters for a custom Java class, you need to either re-record the class or modify your class include file to reflect the changes.
Decision tree for dealing with custom Java classes
- Can you see the object without
Show All Classes checked?
- If yes, then do you get any methods and properties using
Record Class?
- If yes, then use
Record Class to generate a winclass for the custom class. We recommend that you check
Show all methods.
- If no, then do you get any methods and properties using the
CaptureObjectClass() or
CaptureAllClasses() function?
- If yes, then use
CaptureObjectClass() to generate a winclass for the custom class, or
CaptureAllClasses() to generate winclasses for the custom class and all child custom classes.
- If no, then go to Step 1.b.ii. You already know the class, but you will need to determine the public methods.
- If no, then can you see it with
Show All Classes checked?
- If yes, then you need to adjust the
[ClassList] section in
extend\JavaEx.ini.
- Expose classes that are ignored by default, which means with
Show All Classes unchecked, by setting them to
true.
- You may also need to hide some classes that are exposed by default by setting them to
false. This may be true for tables where you see the individual cells but not the entire table, or for classes that are obscured by container or panel classes.
- Uncheck
Show All Classes after you modify the
ClassList, before recording any classes or window declarations.
- Go back to Step 1.
- If no, then that indicates that the component is not derived from AWT Component. You will need to find out from the customer what the custom class is and which public methods are available for that class. The easiest way to determine the public methods is to find it out from the customer, but you can also try using 'javap', which is part of the JDK, to extract the public methods from the class.
- Can you access the object (ObjectA) of this class (Class A) through a method of a different class (Class B) that
Silk Test Classic can recognize? The useful Class B method would only be recorded if you check
Show all methods when recording the class for the Class B object (ObjectB).
- If yes, then does the useful Class B method take only
4Test-compatible values as parameters?
- If yes, then do the methods that you want to call for Class A return
4Test-compatible values and take
4Test-compatible values as parameters?
- If yes, then you should be able to call
ObjectB.invokeMethods() to call the methods for
ObjectA:
ObjectB.invokeMethods ({"ClassBMethod", "ClassAMethod"}, {lArgumentsForClassBMethod, lArgumentsForClassAMethod}).
- If no, then use
ObjectB.InvokeJava(). Within the class that you create for
InvokeJava(), call the Class B method that returns ObjectA, then call the Class A method.
- If no, then use
ObjectB.InvokeJava(). Within the class that you create for
InvokeJava(), call the Class B method that returns ObjectA, then call the Class A method.
- If no, then use
InvokeJava(). You will have to find a
Silk Test Classic-recognizable object that can indirectly be used to access ObjectA through intermediate objects.
- Does
Record Class or the capture class functions give you useful
4Test-accessible methods for the class in question (Class A)?
- If yes, then call the recorded methods directly in your scripts.
- If no, then are the methods that you need to use commented out?
- If yes, then are the methods commented out only because they return values that are not
4Test-compatible, probably because they return custom classes?
- If yes, then are there methods on the returned classes that return
4Test-compatible values and take only
4Test-compatible values as parameters?
- If yes, then you should be able to call
invokeMethods() on the object of interest (ObjectA):
ObjectA.invokeMethods({"ClassAMethodOfInterest", "4TestCompatibleMethodForClassReturnedByClassAMethod"}, {lArgumentsForClassAMethod, lArgumentsForMethodForClassReturnedByClassAMethod})
- If no, then use
InvokeJava() on the object of interest. Call the non-4Test-compatible methods within the class that you create for
InvokeJava(). Make sure that you eventually return a 4Test-compatible value from the
InvokeJava() class.
- If no, then use
InvokeJava() on the object of interest. Call the non-4Test-compatible methods within the class that you create for
InvokeJava(). Make sure that you eventually return a
4Test-compatible value from the
InvokeJava() class.
- If no, then use
InvokeJava() on the object of interest.