At the point of launching tests from the command line, there may arise a need to pass some information to be further used in the tests. In another case, while the script being executed, there may turn up a necessity to find out which parameters the TestComplete has been started with that serves the basis for decision-making. In this recipe, we will deal with the methods of working with parameters from the command line, which have been assigned at the point of starting the TestComplete application.
Launch the TestComplete application with the /ns parameter (this parameter blocks display of the so-called splash screen—the picture that appears on the screen right after the application has been launched—until the main window of the application is successfully opened).
In order to work with command-line parameters, we need to perform the following steps:
- This simple script will make consecutive log entries of all the command-line parameters of TestComplete:
for(var i = 0; i <= BuiltIn.ParamCount(); i++) { Log.Message(BuiltIn.ParamStr(i)); } - In the result of this code, the log will contain two messages: the pathname to the
TestComplete.exefile and the/nsstring.
The BuiltIn.ParamCount method gives us the count of the parameters, which have been passed to TestComplete, while the BuiltIn.ParamStr method allows obtaining a separate parameter, by assigning its index.
Pay attention to the next peculiarity of these methods: zero-indexed element of the BuiltIn.ParamStr method contains the pathname to the executed TestComplete file, however, the BuiltIn.ParamCount method does not take into account this zero-indexed element and returns only the count of the parameters.
Parameters of any of the process can be obtained with the help of the CommandLine property. For instance, in the following example, we receive the entire command line of the
TestComplete parameter:
var cmdLine = Sys.Process ("TestComplete").CommandLine;Since the CommandLine property contains the whole of the command line, working with the parameters is not convenient, which is why it is good to write up a function that would return an array of parameters to be accessed, analogous to the BuiltIn.ParamStr method at work.
At the point of processing the line we should account for the path to the file, any other parameter may be enclosed in quotation marks and contain blank spaces. This is why the logic of the function will be to the following effect:
- We consecutively obtain command-line symbols.
- If the received symbol is not a blank space or a double quotation mark, we simply add the symbol to the parameter-to-be.
- If this is a double quotation mark, we set or disannul a
Booleanflag for substring detection. - If this is a blank space, first, we are supposed to check if we are inside a substring. If this is so, then we add the blank space to the parameter-to-be. If not, we add the current parameter to the array.
In the result, the function for parsing the command line will appear to the following effect:
function parseCommandLine(cmdLine)
{
var chr, parameter = "";
var parameters = [];
var isString = false;
for(var i = 0; i < cmdLine.length; i++)
{
chr = cmdLine.substr(i, 1);
switch(chr)
{
case '"':
isString = !isString;
break;
case ' ':
if(isString)
{
parameter += chr;
}
else
{
parameters.push(parameter);
parameter = "";
}
break;
default:
parameter += chr;
break;
}
}
if(parameter != "")
{
parameters.push(parameter);
}
return parameters;
}And an example of the script, which employs the function in view:
function RunTests()
{
var arr = parseCommandLine(Sys.Process("TestComplete").CommandLine);
for(var i = 0; i < arr.length; i++)
{
Log.Message(arr[i]);
}
}This example outputs all parameters of TestComplete to the test log.