Generic Recommendations

New Recommendations from Qualitia v8.0.0

Qualitia has come up with a new set of rules for creating custom actions in Qualitia 8.0.0 and later. If you have created custom actions to Qualitia version earlier than v8.0.0, then you must edit the existing ones with the following rules.

Making a New Class for Recommendations

The user should create his own You can create a custom class consisting of his your custom actions. The newly generated class can be added in the same package as that of the already supported actions. 

The user has to make sure You must ensure that in the testcasetest case, the ‘name’ and ‘qClass’ fields of action is are set to the correct name of the action and class containing that action respectively. Qualitia 8.0.0 version now uses the concept of java reflection through which the action mentioned in ‘name’ and class mentioned in ‘qClass’ is called directly for action execution. The below following example demonstrates making how to make a new class for custom actions,. 

package <QASpackagename>;

 

import com.qualitia.execution.ActionResponse;

 
 import com.qualitia.execution.ApplicationLogger;

 
 import com.qualitia.models.testcase.ExecutionResult;

 
 import com.webdriverfw.Wrappers.General;

 

 <QASimportlist> 

 

 public class <QASclassname> extends General { 

 

 //Define your customs actions here 

 

 }

Writing Custom Actions in the Accepted Format

The user must strictly follow the pattern for actions which is accepted by Qualitia. The format for actions as per the Qualitia 8.0.0 Version is : 

         public ActionResponse <QASmethodname>(<QASparametername>) { 

     ActionResponse actionResponse = getActionResponse(); 

Qualitia now allows to write code for a custom in the following format. 

   package <QASpackagename>; 

import com.qualitia.execution.ActionResponse;   import com.qualitia.execution.ApplicationLogger;   import com.qualitia.models.testcase.ExecutionResult;   import com.webdriverfw.Wrappers.General; 

  <QASimportlist> 

  

  public class <QASclassname> extends General { 

  

  //Define your customs actions here 

  

  }

 public ActionResponse <QASmethodname>(<QASparametername>) { 

     

     ActionResponse actionResponse = getActionResponse(); 

     ApplicationLogger applicationLogger = actionResponse.getApplicationLogger(); 

     actionResponse.setExecutionResult(ExecutionResult.FAILED); 

     try { 

               // Your code here... 

           applicationLogger.writeToInfoLog(""); 

           actionResponse.setMessage("Successful message"); 

           actionResponse.setExecutionResult(ExecutionResult.PASSED); 

        } catch (Exception ex) { 

           applicationLogger.writeToErrorLog("Exception message", ex); 

           actionResponse.setMessage(“Failed Message”, FailureCategory); 

           actionResponse.setExecutionResult(ExecutionResult.FAILED); 

        } 

        return actionResponse; 

}  

As per the previous Qualita versions before 8prior to v8.0.0 , the actions used to return integer value i.e 0,1,2,-1  which were used to indicate PASSED, FAILED, DEFECT, NOT-EXECUTED respectively .

The return value has been changed to ActionResponse. The actions return ActionResponse which contains 2 parameters Message and ExecutionResult. Before returning the actionResponse and after ActionResponse is returned during the execution of action, the required message and ExecutionResult must be set properly. The primitive datatypes allowed for action parameters are String and Array. 

ApplicationLooger

In the previous Qualitia version,  DataLogger.writeToDebugAndInfoLogs(“”) was used for setting messages. In Qualitia 8.0.0 version, this is replaced by actionResponse.setMessage(“”). The messages which the user wants to set related to execution can be set by actionResponse. 

Qualitia has also introduced ApplicationLogger. If the user wants to set message which is not related to execution, then ApplicationLogger can be used. In general, For action specific logging  the user For actions specific to logs, you can use ApplicationLogger.  

• applicationLogger.writeToInfoLog(""); 

• applicationLogger.writeToErrorLog(""); 

The main purpose of ApplicationLogger is to create logs the ogs to understand the flow of execution. There are 2 types of logs supported for Qualitia: 

• Info Log

• Error Log

Show Link of File in Info Log Section 

Some custom actions may need to write a file during its execution. User You can view that file inside the Info Log of that custom action. If user wants you want to view that the file contents, then he you can click on the Link to report present in the Message section of Info. 

Below The following function needs to be called before retuning returning Action Response to show the link of file files inside the log section. 

showLinkOfFileInLogsSection(String sourceFilePath, ActionResponse actionResponse) 

The sourceFilePath: Path of denotes the file path you write during custom action execution. 

actionResponse: Action Response object 

, and actionResponse denotes the Action Response object. 

The Error logs must be in the catch block of Action. These logs can be seen in Qualitia report which is generated after the execution of the suite. 

Setting an Execution Result

While setting ExecutionResult, user you can make use of ExecutionResult enum where the required results are available. 

• ExecutionResult.PASSED , is used to set this when the action is passed. 

• ExecutionResult.FAILED , is used to set this when the action is failed. 

• ExecutionResult.DEFECT , is used to set this when the action has a defect. 

• ExecutionResult.NOT_EXECUTED ,is used to set this when the action halts the execution halts.  

The message and ExecutionResult that has been set will appear in the final Qualitia report. After writing custom actions in the correct format user needs to make following changes in DirectActionCall class: Aftercreating new class for Custom Actions, he has to create a new method in DirectActionCall class as “executeYour_Class_Name”. The format of the method should be , 

The user can define the Strings “Your_Custom_Action1” and “Your_Custom_Action2” in Actions class as constants. After that the user can use those constants instead of Strings. However, it is not mandatory. It is achieved by editing the Actions class as follows, 

 After adding the method in the required format , edit the switch block of ‘invoke’ method in the format given below, 

  List<Object> paramValues, Your_Class_Name yourClassObject) throws Exception {  

    ActionResponse response;  

    switch (actionName) {  

      case "Your_Custom_Action1":     

        response = yourClassObject.Your_Custom_Action2(Parameters....);    

        break;  

       case "Your_Custom_Action2":  

        response = yourClassObject.Your_Custom_Action2(Parameters....);  

        break;  

        //Remaining custom Actions  

       default:  

       response = executeWebObject(action ,parameter ,yourClassObject, datalogger); 

      OR 

      response = executeMobileObject(action ,parameter ,yourClassObject,                                                 datalogger);       

       // ...Depending on the class which is extended by Custom Class       

       }  

        return response;  

    } 

Example:- 

Here is one brief example on writing custom Actions, showcasing how it was done in old version and how it is done in Qualitia 8.0.0 version. 

If a user wants you want to write a custom action for checking two strings are equal, he you can do it as:  

In Older Versions before 8.0.0

 :  

    public int EqualStrings(String a, String b)  

    {  

    if(a.equals(b))  

    {  

    DataLogger.writeToDebugAndInfoLogs("they are equal");  

    return 0;  

    }  

    else  

    {  

    DataLogger.writeToDebugAndInfoLogs("they are not equal");  

    return 1;  

    }  

    }  

    In Qualitia 8.0.0 Version

 :  

    public AcionResponse EqualStrings(String a, String b)  

    {  

    ActionResponse actionResponse = getActionResponse();  

    if(a.equals(b))  

    {  

    actionResponse.setMessage("they are equal");  

    actionResponse.setExecutionResult(ExecutionResult.PASSED);  

    return actionResponse;  

    }  

    else  

    {  

    actionResponse.setMessage("they are not                                                                                equal”,FailureCategories.Category.INVALID_DATA);  

    actionResponse.setExecutionResult(ExecutionResult.FAILED);  

    return actionResponse;  

    }  

    }

 Adding a Failure Category for a Custom Action

You can add a pre-defined failure category or create a custom category for a custom action.

For more information, refer to Real Time Reporting Portal .

You can add a new category and define new enum implementing Failure Calssification Interface as: 

package com.webdriverfw.Wrappers; 

 Import com.qualitia.execution.failureclassifications.FailureClassificatio; 

 public enum MyCategoriesEnum implements FailureClassification { 

    MY_CUSTOM_CATEGORY1("This is my custom category 1"), 

    MY_CUSTOM_CATEGORY2("This is my custom category 2"); 

  

    private String name; 

  

    MyCategoriesEnum(String s) { 

        name = s; 

    } 

   public String getCategory() { 

        return name; 

    } 

}   

 

 Use it in actions as: 

actionResponse.setMessage("message",FailureCategories.CustomCategory.NEW_CUSTOM_CATEGORY1);

 You can create a new  category as shown in the following: 

 1.) Using String :  

actionResponse.setMessage("message",FailureCategory.newCategory("Categoryname")); 

2.) Using String Constant : You can define constants to customize categories in a separate class. 

package com.webdriverfw.Wrappers; 

 public class MyCategoriesConstants { 

   public static final String MY_CUSTOM_CATEGORY3 = "This is my custom category 1"; 

    public static final String MY_CUSTOM_CATEGORY4 = "This is my custom category 2"; 

} 

Use it in actions as:- 

actionResponse.setMessage("message",FailureCategory.newCategory(MY_CUSTOM_CATEGORY3));