Create a New Assertion

Using the SDK › Extending Assertions › Create a New Assertion

Create a New Assertion

The assertions that the DevTest Solutions provides contain most of the logic that is required to test enterprise software. However, you can create your own assertion to handle a specific situation.

DevTest provides built-in support for custom assertions. To create a custom assertion, you create a Java class that extends com.itko.lisa.test.Assertion (in lisa-core-8.0.0.jar). This class handles most of the behind-the-scenes logic that is required to execute the assertion, and provides a nice user interface in the model editor. If you have an existing Java class that extends com.itko.lisa.test.CheckResult, it is still supported, but this class is deprecated and not recommended.

Follow these steps:

Create a Java class that extends com.itko.lisa.test.Assertion.
This class tells the DevTest that your class is a custom assertion and provides you with the needed assertion functionality.
```
public class AssertionFileStartsWith extends Assertion
{
 
}
```
Implement the required getTypeName method.
This method provides the name that is used to identify the custom assertion in the model editor.
```
public String getTypeName()
{
    return "Results File Starts With Given String";
}
```
The string that the getTypeName method returns is the default name of a new assertion.
Handle custom parameters to the assertion.
Some assertions require more information than is provided in the node execution result. In this case, provide a parameter that allows the user to specify that information in the Assertions tab of the model editor.

Implement the abstract getCustomParameters method. In this method, you create a ParameterList and add a Parameter for each parameter to the assertion. The constructor for the Parameter takes the following:
- A string that provides the label for the parameter in the user interface.
- A string that provides the key to store the value of the parameter in a Map.
- A string representing the value of the parameter.
- The type of the parameter.
In this example, the custom assertion takes one parameter, the string to find in the file. The rest of the code provides support for the parameter.
```
public static final String PARAM = "param";
  
private String param = "";
 
...
 
public String getParam()
{
    return param;
}
 
public ParameterList getCustomParameters()
{
    ParameterList pl = new ParameterList();
    pl.addParameter( new Parameter( "Starts With String", PARAM, param, String.class ) );
    return pl;
}
```
Initialize the custom assertion object with the value of the DOM Element.
When DevTest tries to execute an assertion, it first creates an instance of the custom class. It then calls the initialize method, passing the XML element that defined the assertion. You must store the values of the parameter child elements in the new instance.

For example, the test case XML can include an assertion that looks like the following example:
```
<CheckResult name="CheckThatFile"
    log="Check if the node FTP'd a file that starts with 'All Visitors'"
    type="com.mycompany.lisa.AssertFileStartsWith" >
<then>finalNode</then>
<param>All Visitors</param>
</Assertion>
```
In the initialize method, you must get the text "All Visitors" into the param member variable. The following code grabs the text from the child element named param and checks to ensure that it is not null.
```
public void initialize( Element rNode ) throws TestDefException
{
    param = XMLUtils.getChildText( XMLUtils.findChildElement( rNode, PARAM ) );
    if( param == null )
    throw new TestDefException( rNode.getAttribute("name"),
    "File Starts With results must have a Starts With String parameter specified.", null );
}
```
You are free to use whatever means you prefer to read from the DOM Element. You can use a convenience class named XMLUtils, as seen in the previous example.
Implement the checking logic with the evaluate method.
The TestExec parameter provides access to the test environment, such as logs and events. The Object parameter provides access to results returned from executing the node. The Boolean return type returns true if the assertion is true. Otherwise it returns false.

The following code verifies that the first line of the file that is passed from the node contains the string that is stored in the param parameter. This code returns true only if the file starts with that string.
```
public boolean evaluate( TestExec ts, Object oresult )
{
    if( oresult == null )
        return false;
    FileDataObject fdo = (FileDataObject)oresult;
    String firstline = fdo.getFileFirstLine();
    return firstline.startsWith(param);
}
```
As an author of an assertion, simply declare whether the assertion as defined is true or false. Do not worry about the steps to execute after the state is returned. The workflow engine evaluates whether that is considered a fired assertion.
(Optional) Implement the setValueDetail method to integrate into Portal Test Monitoring facility.
You can provide a detailed message for the assertion about the actual value and the expected value.
```
public void setValueDetail(Object actual, Object expectation)
```