TestExecute Command Line

This section describes the command line of TestExecute.

Note that TestExecute has two executables (32-bit and 64-bit ones):

• The 32-bit executable of TestExecute is located in the <TestExecute>\Bin\ folder.

• The 64-bit executable of TestExecute is located in the <TestExecute>\x64\Bin\ folder.

Here the parentheses mean the group of command-line arguments. The “|” means OR, for example, “/r | /run” means you can use either /r OR /run. Square brackets mean the argument or group of arguments is optional.

Prerequisites

Calling from CI systems

To run TestComplete tests, an interactive user session is required. CI systems like Jenkins or Bamboo typically use non-interactive user sessions. So, if you run TestExecute from a command line from the CI systems, then your tests will not run successfully.

To work around the issues, we recommend that you use the SessionCreator command line utility — it supports opening interactive user sessions. If you use Jenkins, you can also try a special plugin.

Command-line arguments

Below is the description of the command-line arguments that TestExecute accepts:

• file_name - Launches TestExecute and loads the specified project (.mds file) or project suite (.pjs) into it.

• /run (or /r) - Commands TestExecute to run tests provided by the opened project suite, project, a project item, or a script routine. The action TestExecute will perform depends on what other command-line arguments are specified:

  No other arguments specified

  TestExecute will run the tests provided by the opened project suite.

  /project:project_name

  TestExecute will run all enabled test items of the specified project. Project_name is the name of the project as it is shown in TestComplete Project Explorer panel. You can view the list of test items in TestComplete, in the Execution Plan editor of the project.

  TestExecute will run only the enabled test items, it will not run the disabled items.

  /project:project_name  /projectitem:item_name

  TestExecute will run test(s) provided by the specified project item. You can view project items in the TestComplete Project Explorer panel. Project_name specifies the name of the project that holds the desired project item (use the same name as the name shown in the Project Explorer panel). Item_name is the name of the desired project item.

  Note:

  Using this argument, you can run only those project items that have the Run item in their context menu. For example, in this way, you can run the Network Suite and ODT project items.

  /project:project_name  /test:test_name

  TestExecute will run the specified test (or tests).

  Project_name specifies the name of the project that holds the needed test (use the same name as that shown in the Project Explorer panel).

  Test_name specifies the test to run. It can be either the full name of the needed test or a tag:

  Full name

  Tag

  Full name

  For test items, the full name is specified according to the item hierarchy in the Execution Plan editor of the project, including parent test items and groups. Enclose the test full names in quotation marks. For example:

  "ProjectTestItem1"

  "ProjectTestItem1|ProjectChildTestItem1"

  "Group1|ProjectTestItem1"

  Note:

  TestExecute executes only those test items that are enabled in the TestComplete Execution Plan editor. The disabled items are not run.

  For individual tests, the full name includes the name of the collection, to which the test belongs, and the test name separated by the pipe character. For script tests, the full name also includes the name of the unit. Enclose your test full names in quotation marks.

  For example:

  "KeywordTests|Test1"

  "LLCollection1|LLP1"

  "ManualTests|ManualTest1"

  "ReadyAPI1|Test1"

  "UnitTesting1|NUnit1"

  "Script|Unit1|Main"

  "NetworkSuite|Jobs|Job1|Job1" (For a network suite’s jobs, the name of the Jobs collection and the name of the job are the same.)

  "NetworkSuite|Jobs|Job1|Task1"

  The test name should not contain names of logical project folders.

  Tag

  To run scripts, keyword tests, or BDD scenarios that match a tag, specify the tag name in the @tag_name format. Enclose the tag in quotation marks. For example:

  "@Tag1"

  To learn how run tests that match a tag expression, use the /tags argument (see below).

  /project:project_name  /unit:unit_name  /routine:routine_name

  TestExecute will run the specified script routine. Project_name specifies the name of the project to which the routine belongs. Unit_name specifies the name of the unit holding the desired routine. Routine_name is the name of the script routine to be called. The routine to be called must not use any parameters and return any value. Project_name and unit_Name should be the same as the project and unit names shown in the Project Explorer.

  /project:project_name  /tags:tag_expression

  TestExecute will run all tests and BDD scenarios of the specified project that match tag_expression.

  Project_name specifies the name of the project that holds the needed tests (use the same name as that shown in the Project Explorer panel).

  Tag_expression specifies the needed tag or tag expression.

  Tag expression syntax

  Tag expression syntaxTag expression syntax

  • Use @ before tag names, that is, use @tag1 rather than tag1.

  • To combine tags, use the and, or and not operations, for example:

    @tag1 or @tag2
    @tag1 and not @tag3
    not @tag5

    These operations don’t depend on the scripting language you use in your TestComplete project. That is, for example, in JavaScript projects you should use and, or and not rather than &&, || and !  —

    @tag1 and not @tag2  ← Correct!
    @tag1 && !@tag1      ← Incorrect!

  • If needed, you can use braces to group tags, for example:

    @tag1 and (@tag2 or @tag3)
    (@tag1 or not @tag2) and (not @tag3 or @tag4)

  Note: If the command has both the test and tags arguments specified, the test argument will be ignored.
  If the tags argument specifies an empty tag expression, the command will execute all tagged tests and scenarios of the specified project.

  Notes:

  • Pay attention to the colon between the argument name and the element to which the argument refers. The colon separates the argument name and the element name. Do not insert spaces before or after the colon.

  • The argument names can be shortened. /project can be replaced with /p, /projectitem - with /pi, /unit - with /u and /routine - with /rt.

• /exit (or /e) - If this argument is used along with the /run argument, TestExecute will close after the project (or project suite) run is over. If the /exit command-line argument is used without /run, then neither the specified project (project) suite will be run, nor will TestExecute be closed.

  Note that if you run tests, the project (or project suite) file will be changed because it will contain a reference to the new log file. TestExecute will display the Confirm dialog asking you to save the changes. To suppress displaying the dialog on exit, specify the /SilentMode command-line argument along with /exit.

• /SelfHealing:On | Off (or /SH:On | Off) - Starting from version 14.40, this argument is available only if you have an active license for the Intelligent Quality add-on. Enables (On) or disables (Off) self-healing tests in TestExecute.

  If self-healing tests are enabled (default behavior) and TestExecute fails to find a tested object during the test run, it will try to find a replacement object to use it in the test instead of the missing one and will continue the test run. After the test run is over, the test log will include a warning message informing about the issue and suggesting to update the mapping criteria of the missing object to match the replacement object. Open the project in TestComplete and update the criteria as suggested.

  If self-healing tests are disabled and TestExecute fails to find a tested object during the test run, it will report the “The Object Does Not Exist” error. Depending on the project settings, it will stop the test run.

• /PSVar:VarName=VarValue (or /psv)   /PrjVar:VarName=VarValue (or /pv)

  TestExecute will assign a specified value to a specified project suite or project variable at runtime.

  Variable values you pass via the command line are temporary. At the beginning of the test run, they overwrite the initial value of appropriate variables of your project or project suite. After the test run is over, the variable values are restored to their initial state.
  If the variable you set via the command line does not exist in your project or project suite, it will be created at the beginning of the test run and removed after the test run is complete.
  If you run several projects that have a project variable with the same name, the command will set the variable value in all executed projects.

• /AccessKey:access_key - If you use SmartBear License Management to control your product licenses, use this parameter to specify the access key assigned to your SmartBear account. This key will be used to license the product instance.

  Learn how to get the access key

  Learn how to get the access keyLearn how to get the access key

  1. Log in to the SmartBear License Management system at manage.smartbear.com with your SmartBear account.

  2. Click  > Access Key at the top right of the page.

  3. From the resulting dialog, copy the access key to the clipboard.

  

  Click the image to enlarge it.

• /ErrorLog:file_name - Commands TestExecute to save information on the errors that occurred during the run to the text file the file_name parameter specifies. This file will include information on the errors that occurred in your tests and on the errors that did not allow opening the project or running the test (for example, an incorrect project path).

  Notes:

  • Important: file_name should specify a non-existent file. If you specify the name of an existing file, TestExecute will fail to run the test.

  • We recommend that file_name specify the fully-qualified file name. If the parameter value does not include the folder path, TestExecute will save the file to the current working folder (by default, it is the project folder).

• /SilentMode - If this argument is specified, TestExecute works in silent mode, that is, it neither displays dialogs, nor informs you about errors or warnings. The dialogs and messages to be displayed are handled as if you pressed the default button in them. Information about these dialogs and messages is saved to the following file:

  <Users>\<User_Name>\AppData\Roaming\SmartBear\TestExecute\15.0\Silent.log

  The file should not be read-only or locked by another application.

  The errors that occur during the test run are posted to the test log.

• /ExportLog:file_name (or /el:file_name) - Commands TestExecute to export test results to a file specified by the File_name parameter after the test run is over.

  Notes:

  • Important: file_name should specify the name of a non-existent file. If it specifies an existing file, TestExecute will fail to run the test.

  • It is recommended that file_name specify the fully-qualified file name. If the parameter value does not include the folder path, TestExecute saves the file to the current working folder (by default, it is the project folder).

  • You can export results to a file in one of the following formats:

    • .mht

    • .tcLogX

    • .html

    • .htm

• /ExportSummary:file_name (or /es:file_name) - Commands TestExecute to generate a Summary report for the current test run and to save it in the JUnit report format to the XML file that the file_name parameter specifies.

  The report will include the total number of run tests, the number of passed tests and the number of failed tests.

  Notes:

  • If the file_name parameter specifies an existing file, TestExecute will overwrite it.

  • We recommend that the file_name parameter specify the fully-qualified file name. If the parameter value does not include the folder path, TestExecute will save the file to the current working folder (by default, it is the project folder).

• /NoSummary - TestExecute will not include the Summary report in the test log exported by using the /ExportLog command-line argument. It does not affect the /ExportSummary argument.

• /Timeout:time_in_seconds - Timeout for the TestExecute session in seconds. This timeout includes both the TestExecute startup time and the test run time. If TestExecute is still running when the timeout elapses, it posts an error to the test log (if a test is running) and closes. Possible values are 30 .. 4 294 967 seconds (49.7 days). If the specified value is out of range, the closest in-range value is used.

• /DoNotShowLog - If this argument is specified, TestExecute does not show test results automatically after the test run is over. If the argument is not specified, test results are shown in Internet Explorer right after the test has finished.

• /ShareResults:file_to_save_url (or /shr:file_to_save_url) - Commands TestExecute to upload the test results to our online storage and to save the resulting link to the file_to_save_url file.

  File_To_Save_URL can specify a fully qualified file path, or it can specify the file name only. If the folder path is omitted, TestExecute will save the file to the current TestExecute folder. If a project is run, the current folder is the project folder, if the project suite is run, the current folder is the project suite folder.

  File_To_Save_URL must specify a nonexistent file, otherwise TestExecute will not share the results and will report an error.

• /SharedResultsName:name (or /shrn:name) - Can only be used with the /ShareResults argument above. It specifies the name that will be used for the shared results report. If omitted, the name of the log item will be used.

• /SharedResultsExpireIn:days (or /shrei:days) - Can only be used with the /ShareResults argument above. It specifies the number of days during which the shared results will be available. Possible values are:

  • 1
  • 7
  • 14

  If the argument is omitted, the shared results will expire in 14 days. If a non-supported value is specified, the test log will not be shared, and an error will occur.

• /SkipVisualizerData - Can be used with /ExportLog or with /ShareResults, or with both. If this argument is specified, TestExecute will not include images captured during test recording and test run in the exported results. This can help reduce the exported results' size.

• /ForceConversion - If this argument is specified and TestExecute is running in Silent mode, TestExecute automatically converts projects created in earlier versions of the tool to the new format when they are opened.

• /install:extension_name (or /ip:extension_name) - Installs the specified extension and enables it. Extension_name specifies the fully-qualified name of the desired plugin (.pls file).

  Note:

  You cannot use this command-line parameter to install a script extension.

• /uninstall:extension_name (or /up:extension_name) - Uninstalls the specified extension. Extension_name specifies the fully-qualified name of the plugin (.pls file) that corresponds to the extension you want to uninstall.

  Notes:

  • This command does not delete the actual file from the disk.

  • You cannot use this command-line parameter to uninstall a script extension.

• /ns - Starts TestExecute without displaying the “TestExecute has started” taskbar notification.

• /agpatcheroff - Disables auto-patching of Silverlight applications. To learn more about Silverlight auto-patching, refer to the TestComplete documentation.

• /UsageStatistics:file_name (or /US:file_name) - Commands TestExecute to collect statistics on usage of Name Mapping items during test runs. TestExecute will save the gathered data to the specified file. You can then use this data to find and remove unused objects to clear the Name Mapping repository. To learn how to do it, see TestComplete documentation.

  If the file name includes spaces, enclose it in quotes:

  TestExecute.exe /UsageStatistics:"c:\some shared folder\Name Mapping Data.stat"

• /EnableModule:module_set - Enables or disables available TestExecute modules and add-ons on startup. module_set is the name of the module or add-on to enable, which can be:

  • Desktop

  • Mobile

  • Web

  • Intelligent Quality (or IntelligentQuality, or IQ)

  If a module or an add-on is not specified, it will be disabled. If the module or add-on name includes spaces, enclose it in double quotes: /EnableModule:"Intelligent Quality".

  For example, the following command will run TestExecute with the Web module enabled. The Desktop and Mobile modules and the Intelligent Quality add-on will be disabled:

  TestExecute.exe /EnableModule:Web

  Note: If you start TestExecute with this command-line argument, the Install Extensions dialog will be disabled.

• /RestServerPort:port - If the REST API plugin is installed and enabled in TestExecute, it commands the TestExecute RESTful service to use the specified port. Otherwise, the service will use the default port - 2377.

  Note:

  If a firewall or an antivirus is running on your computer, make sure that it allows traffic through the specified port.

• /ZephyrVersion:version - If test items of your TestComplete project are bound to Zephyr tests in your Jira project, this argument specifies the release version of your Jira project to which test results will be added.

  You can use this argument only if you have TestExecute version 14.10 or later.

• /ZephyrCycle:cycle - If test items of your TestComplete project are bound to Zephyr tests in your Jira project, this argument specifies the test cycle in your Jira project to which test results will be added.

  You can use this argument only if you have TestExecute version 14.10 or later.

• /DisableExternalReporting - Disables sending test results to external test management systems (for instance, Zephyr Squad).

• /ForkLimitUnlimited and /ForkLimitBrowser - Depending on the command-line argument used, if you use Name Mapping in your tests, the test engine will search for a tested web page either in all web browsers running in your system or only in your current web browser (default behavior).

Note: If neither the release version, nor test cycle are specified, TestExecute will send test results to the release version and test cycle that your project settings specify. If the project settings do not specify the version and release either, TestExecute will send the test results to a default release version (Unscheduled ) and to a default test cycle (Ad hoc).

See Also

TestExecute Exit Codes