When to Record Classes

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

  1. Can you see the object without Show All Classes checked?
    1. If yes, then do you get any methods and properties using Record Class?
      1. If yes, then use Record Class to generate a winclass for the custom class. We recommend that you check Show all methods.
      2. If no, then do you get any methods and properties using the CaptureObjectClass() or CaptureAllClasses() function?
        1. 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.
        2. If no, then go to Step 1.b.ii. You already know the class, but you will need to determine the public methods.
    2. If no, then can you see it with Show All Classes checked?
      1. If yes, then you need to adjust the [ClassList] section in extend\JavaEx.ini.
        1. Expose classes that are ignored by default, which means with Show All Classes unchecked, by setting them to true.
        2. 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.
        3. Uncheck Show All Classes after you modify the ClassList, before recording any classes or window declarations.
        4. Go back to Step 1.
      2. 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.
        1. 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).
          1. If yes, then does the useful Class B method take only 4Test-compatible values as parameters?
            1. 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?
              1. If yes, then you should be able to call ObjectB.invokeMethods() to call the methods for ObjectA: ObjectB.invokeMethods ({"ClassBMethod", "ClassAMethod"}, {lArgumentsForClassBMethod, lArgumentsForClassAMethod}).
              2. 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.
            2. 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.
          2. 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.
  2. Does Record Class or the capture class functions give you useful 4Test-accessible methods for the class in question (Class A)?
    1. If yes, then call the recorded methods directly in your scripts.
    2. If no, then are the methods that you need to use commented out?
      1. If yes, then are the methods commented out only because they return values that are not 4Test-compatible, probably because they return custom classes?
        1. If yes, then are there methods on the returned classes that return 4Test-compatible values and take only 4Test-compatible values as parameters?
          1. If yes, then you should be able to call invokeMethods() on the object of interest (ObjectA): ObjectA.invokeMethods({"ClassAMethodOfInterest", "4TestCompatibleMethodForClassReturnedByClassAMethod"}, {lArgumentsForClassAMethod, lArgumentsForMethodForClassReturnedByClassAMethod})
          2. 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.
        2. 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.
    3. If no, then use InvokeJava() on the object of interest.