Recommendations and Rules for Custom Actions
- ravi.chandran (Unlicensed)
Generic Recommendations
For creating the custom actions for Selenium Webdriver, you need to create the action in Java and then map the action into Qualitia Automation Studio. You can use any IDE tool like Eclipse.
The following are some rules that must be considered when creating custom actions:
The parameter data types supported by Qualitia are String and Array. If an array parameter is used in Qualitia for the custom action, then custom action parameter should be of the type Object in Custom Action function. The parameter can then be type-casted into the data type which is required in the action.
For example, the object parameter can be type-casted into the array list.Based on the standard Java coding rules, actions should not be created in the default package. For better maintenance, it is recommended to use user-defined packages for development.
It is recommended to put a prefix when defining a name for new custom actions for easy identification.
No two custom actions can have the same function name in the same class. Function overloading is not allowed. Duplicate function names in different classes are allowed (not recommended).
Once the action is mapped into Qualitia and used in a test case, do not change the existing signature or other details of the actions or the classes created. The functionality of the action can be modified. Do not delete the custom actions or custom classes that are used in test cases.
If the custom action belongs to any object type (such as WebEdit, WebElement, and so forth), ensure you add the objectInfo data type parameter while developing the code of an action.
While mapping actions into Automation Studio, it is important to map the action using <package.class> hierarchy.
Objects should be added under appropriate Qualitia classes while mapping custom actions into Qualitia Automation Studio
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
You can create a custom class consisting of your custom actions. The newly generated class can be added in the same package as that of the already supported actions.
You must ensure that in the test case, the ‘name’ and ‘qClass’ fields of action are set to the correct name of the action and class containing that action respectively. Qualitia 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 following example demonstrates 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
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 prior 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 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
For actions specific to logs, you can use ApplicationLogger.
applicationLogger.writeToInfoLog("");
applicationLogger.writeToErrorLog("");
The main purpose of ApplicationLogger is to create 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 need to write a file during its execution. You can view that file inside the Info Log of that custom action. If you want to view the file contents, then you can click the Link present in the Message section of Info.
The following function needs to be called before returning Action Response to show the link of files inside the log section.
showLinkOfFileInLogsSection(String sourceFilePath, ActionResponse actionResponse)
The sourceFilePath denotes the file path you write during custom action execution, 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, you can make use of ExecutionResult enum where the required results are available.
ExecutionResult.PASSED is used to set when the action is passed.
ExecutionResult.FAILED is used to set when the action is failed.
ExecutionResult.DEFECT is used to set when the action has a defect.
ExecutionResult.NOT_EXECUTED is used to set when the action halts the execution.
The message and ExecutionResult that has been set will appear in the final Qualitia report.
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 you want to write a custom action for checking two strings are equal, you can do it as:
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 | RealTimeReportingPortal ViewingaFailureSummaryReport .
You can add a new category and define new enum implementing Failure Calssification Interface as:
Use it in actions as:
You can create a new category as shown in the following:
1.) Using String :
2.) Using String Constant : You can define constants to customize categories in a separate class.
Use it in actions as:-