Previous Topic: Extending FiltersNext Topic: Deploy a New Filter


Create a New Filter

The filters that the DevTest Solutions provides includes most of the logic that is required to test enterprise software. However, you can create your own filter to handle a specific situation. DevTest provides built-in support for custom filters.

Follow these steps:

  1. Create a Java class that extends com.itko.lisa.test.FilterBaseImpl.

    This class tells DevTest that your class is a custom filter.

    public class FilterFileFirstLine extends FilterBaseImpl
    {
      
    }
    
  2. Implement the required getTypeName method.

    This method provides the name that is used to identify the custom filter in the model editor.

    public String getTypeName()
    {
        return "File First Line Filter";
    }
    
  3. Define the parameters to the filter.

    For each item in the Filter Attributes section of the Filters tab in the model editor, add a Parameter to the ParameterList for the filter. In this example, the custom filter takes two parameters:

    The following code creates the two parameters:

    public ParameterList getParameters()
    {
        ParameterList p = new ParameterList();
        p.addParameter( new Parameter( "Is FTP", ISFTP_PARAM, new Boolean(isftp).toString(), Boolean.class ) );
        p.addParameter( new Parameter( "New Property", PROP_PARAM, prop, TestExec.PROPERTY_PARAM_TYPE));
        return p;
    }
    
  4. Initialize the custom filter object with the value of the DOM Element.

    When DevTest tries to execute a filter, it first creates an instance of the custom class. DevTest then calls the initialize method, passing the XML element that defined the filter. You must store the values of the parameter child elements in the new instance.

    For example, the test case can include a filter that looks like the following example:

    <Filter type="com.mycompany.lisa.ext.filter.FilterFileFirstLine"
        isftp="true" prop="THE_LINE" />
    

    In the initialize method, set the isftp variable to true and set the prop variable to THE_LINE.

    static private String ISFTP_PARAM = "isftp";
    static private String PROP_PARAM = "prop";
    private String prop;
    private boolean isftp;
    //...
     
    public void initialize( Element e ) throws TestDefException
    {
        try {
            String s = XMLUtils.findChildGetItsText( e, ISFTP_PARAM ).toLowerCase();
            if( s.charAt(0) == 'y' || s.charAt(0) == 't' )
                isftp = true;
            else
                isftp = false;
        }
        catch( Exception ex ) {
            isftp = false;
        }
        prop = XMLUtils.findChildGetItsText( e, PROP_PARAM );
        if( prop == null || prop.length() == 0 )
        prop = "FILE_FIRST_LINE";
    }
    

    This code uses a utility class in lisa-util-8.0.0.jar named com.itko.util.XMLUtils. This class finds child tags of the given parent tag and reads the child text of the tag. This approach is useful because DevTest automatically writes the XML representation of filters by making each of the Parameter objects in getParameters a child tag of the Filter tag. Each parameter key becomes the tag name and the child text of the tag is the value.

    If a filter defines the prop key, then the default name of the filter is {{propValue}}. propValue is the value of the prop parameter. If a filter does not define the prop key, then the default name of the filter is the string that the getTypeName method returned. The FilterFileFirstLine sample class defines this key as:

    static private String PROP_PARAM = "prop"; 
    
  5. Because the filters execute before and after the test step, you get two chances to implement the filter logic.

    Implement the filter logic before node execution with the subPreFilter method. The TestExec parameter provides access to the test environment, such as logs and events. If the filter sets a new node to execute, the Boolean return type returns true. Otherwise, it returns false.

    In this example, we are not interested in filtering before the node executes, so the subPreFilter method does nothing.

    public boolean subPreFilter( TestExec ts ) throws TestRunException
    {
        // don't have anything to do...
        return false;
    }
    

    Implement the filter logic after node execution with the subPostFilter method. The TestExec parameter provides access to the test environment, such as logs and events. If the test should continue as normal, the Boolean return type returns false. Otherwise, it returns true.

    In this example, we store the first line of the file that is returned from the node in the new property. ftp:// is prepended if the isFTP box is selected.

    A DevTest user can use a filter at either the test step level or the test case level. Add logic to the filter that verifies whether the result is the proper state to run the filter. For example, if your filter assumes that the LASTRESPONSE holds a FileDataObject, then verify that before executing the filter logic.

    public boolean subPostFilter( TestExec ts ) throws TestRunException
    {
        try {
            Object oresponse = ts.getStateObject( "LASTRESPONSE" );
            if (!(oresponse instanceof FileDataObject))
                return false;
            FileDataObject fdo = (FileDataObject)oresponse;
            String firstline = fdo.getFileFirstLine();
            if((firstline ==null) || (firstline.equals(""))) {
                ts.setStateValue( prop, "" );
                return false;
            }
            if( isftp )
                firstline="ftp://" + firstline;
            ts.setStateValue( prop, firstline );
            return false;
        }
        catch( Exception e )
        {
            throw new TestRunException( "Error executing FilterFileFirstLine", e );
        }
    }