Partager via

Tux Command-Line Parameters (Windows Embedded CE 6.0)

  • Article

1/6/2010

The Tux client provides much of the functionality for Tux. You can run the Tux client in stand-alone mode or in conjunction with the Windows Embedded CE 6.0 Test Kit (CETK) server.

Syntax

tux [-b] [-e] [-s file_name | -d test_dll] [-c parameters] [-r seed] 
[-x test_case] [-l | -lv] [-t address] [-n] [-h] [-k address] [-m] 
[-o] [-f file_name] [-a] [-z timeout]

Parameters

  • -b
    Breaks after each Tux DLL loads.
  • -e
    Disables exception handling.
  • -s filename
    Specifies the Tux suite file to load and execute.
  • -d test_dll
    Specifies the Tux DLL to load and execute.
  • -c parameters
    Command line to pass to the Tux DLL.
  • -r seed
    Specifies the integer starting random seed.

  • -x test_case
    Specifies which test cases to run. You can specify a single test case or a range of test cases, as shown in the following command line.

    tux -x10,12,15-20

  • -l
    Lists the test cases in the Tux DLL specified by the -d parameter.
  • -lv
    With greater verbosity, lists the test cases in the Tux DLL specified by the -d parameter.
  • -t address
    Specifies the name of the computer running the CETK server. Use -t with no arguments to specify a local server.
  • -n
    Runs tests in kernel mode.
  • -h
    Displays the list of command line parameters for Tux.

The following table shows the Tux parameters that are enabled when Kato.dll is present.

  • -k address
    Specifies the name of the computer running the CETK server. Use -k with no arguments to specify a local server.
  • -m
    Logs all Kato output as XML.
  • -o
    Logs all Kato output to the debugger.
  • -f filename
    Logs all Kato output to output file filename.
  • -a
    Appends data to the output file. Use this parameter with the -f parameter.

The following table shows a Tux parameter that is enabled when Toolhelp.dll is present.

  • -z timeout
    Cancels an existing run of the Tux DLL that is specified by the -d parameter.

    If you specify -z with no arguments, Tux exits after the current test case in the specified Tux DLL ends.

    If you specify a timeout value, Tux waits for as long as the specified number of seconds for the test case to end. If the test case does not end after the specified wait time, Tux exits.

    For example, if Tux is running the Gdiapi.dll test module and you run the command tux -d gdiapi.dll -z05, Tux waits 5 seconds for the current test case in Gdiapi.dll to end, and then exits. Note that there is no space between the -z flag and the timeout number.

These parameters are discussed further below.

  • -b
    This parameter is often useful for debugging a Tux test DLL. Some debuggers require that a test module be physically loaded into memory before a breakpoint can be set in that test module. Because the Tux client dynamically loads test modules at run time, it can be difficult to set a valid breakpoint in your test module. The -b parameter forces the Tux client to break to the debugger after your test module has been fully loaded, but before any messages have been sent to your ShellProc function. This behavior gives you an opportunity to set a breakpoint in your test module and then resume execution.
  • -e
    This parameter turns off the default exception handling built into the Tux client. By default, the Tux client traps all exceptions that occur while running in your module, reports them back to you and then continues running with the next test. The -e parameter is useful when debugging a Tux test module.

  • -sfilename
    This parameter allows the Tux client to load a test suite file. A test suite file is a script of test DLL modules and test cases to run within each test module. If you use this parameter while running the CETK server with the -t parameter, the script loads but does not execute until directed to do so by the server. If you use this parameter in stand-alone mode without the -t parameter, the Tux client loads the script and immediately executes it. For Windows Embedded CE, suite files can reside on the Windows Embedded CE-based device across the CESH connection remotely. Tux first attempts to find the files on your development workstation. If Tux fails to find the files on the development workstation, Tux searches the Windows Embedded CE-based device for the files. If you want to force Tux to search for files only on the target device, you can prefix the path with cesh:. The following command line shows the syntax for this option.

    tux -s cesh:test.tux

    You can also specify paths relative to the CESH directory on the target device, as shown in the following command line.

    tux -s cesh:..\suites\test.tux

  • -dtest_dll
    This parameter allows the Tux client to load one or more default test modules. You can use this parameter more than once for a given command line to load multiple Tux test modules. If you use this parameter while running the CETK server with the-t parameter, the test modules load but do not execute until directed to do so by the server. If you use this parameter in stand-alone mode with no -t parameter, the Tux client loads the test modules and immediately begins to execute the specified tests for each test module. For more information, see the descriptions for the –x and –l parameters.
  • -cparam_str
    This parameter allows you to pass a parameter string to the Tux test DLL itself. The parameter string that you pass is associated with the DLL most recently specified with the -d parameter. This behavior allows you to specify different parameters for each Tux test DLL. If the string that you specify contains spaces or other special characters, then you should surround the string with quotation marks.
  • -rseed
    This parameter allows you to specify a starting random seed. The seed you pass is associated with the DLL most recently specified with the -d parameter. This behavior allows you to specify a different random seed for each Tux DLL.

  • -xtest_case
    This parameter allows you to specify a test case or a range of test cases to run. You must specify the appropriate identifier for each test case, which may be obtained by using the –l parameter. The values you pass are associated with the DLL most recently specified on the command line with the -d parameter. This behavior allows you to specify different test cases for each Tux test DLL. You can specify this parameter multiple times for a single DLL, as shown in the following command line.

    tux -x10 –x15-20

    You can also combine the ranges into a single parameter, as shown in the following command line.

    tux -x10,15-20

    If you use this parameter while running the CETK server with the -t parameter, the test cases specified are selected but do not execute until directed to do so by the server. If you use this parameter in stand-alone mode with no -t parameter, then the Tux client load the test modules and immediately begins executing the specified tests for each test DLL module. If no –x parameter is specified for a given DLL, the default behavior is to run all tests when the Tux client runs in stand-alone mode.

  • -l
    This parameter causes the Tux client to display the contents of all Tux test DLLs specified with the –d parameter. The listing also shows the identifiers associated with each test case. You can use these identifiers with the –x parameter. When you use the –l parameter, all arguments other than –d are ignored. This parameter provides information and does not run any test cases.

  • -n
    This parameter causes tests to be run in kernel mode using ktux.dll. This flag requires the user to have sufficient privilege to load in the kernel.

    Note

    Processes running under kernel mode cannot be terminated through target control, so the kp command in target control will not be able to terminate the process.

  • -taddress
    This parameter specifies the location of the CETK server. The address parameter can be a computer name or an IP address. If you do not use the -t parameter, Tux assumes stand-alone mode. You must specify either the -s parameter to load and execute a test suite or the -d parameter to load and execute a test module. If no address is given with the -t parameter, the Tux client uses the IP address of the development workstation.
  • -h
    This parameter generates a list of Tux parameters.
  • -kaddress
    This parameter specifies the location of the CETK server. The address parameter can be a computer name or an IP address. If no address is given with the -t parameter, the Tux client uses the IP address of the development workstation. This parameter sends all Kato output to the CETK server. This output is in addition to the output to a file and the debugger, if you specify the -f and -o parameters.
  • -m
    This parameter sends all output to an XML file.
  • -o
    This parameter sends all Kato output to the debugger. This output is in addition to the output to the CETK server and a file, if you specify the -k and -f parameters.

  • -ffilename
    This parameter saves all Kato output to a file. This output is in addition to the output to the CETK server and the debugger, if you specify the -k and -o parameters. The default behavior is to overwrite any existing file of the same name. To override the default behavior and append information to the file, use the -a parameter along with the -f parameter. For Windows Embedded CE, you can prefix the file name with cesh: if you want to create the file on the Release Directory File System (Relfsd) of a target device through the CESH connection. The following command line shows this technique.

    tux -d test.dll -f cesh:test.txt

    You can also specify paths relative to the CESH directory on the target device, as shown by the following command line.

    tux -d test.dll -f cesh:..\logs\test.txt

    If cesh: is not specified, the file is created on the target device.

  • -a
    This parameter can be used with the -f parameter to append data to a log file rather than overwriting the existing log file.

  • -ztimeout
    This parameter stops a running Tux DLL. This parameter has an effect only if Toolhelp.dll is present. Use the -d parameter to specify the Tux DLL to stop.

    If you specify -z with no arguments, Tux exits after the current test case in the specified Tux DLL ends.

    If you specify a timeout value, Tux waits for as long as the specified number of seconds for the test case to end. If the test case does not end after the specified wait time, Tux exits.

    For example, if Tux is running the Gdiapi.dll test module and you run the command tux -d gdiapi.dll -z05, Tux waits 5 seconds for the current test case in Gdiapi.dll to end, and then exits. Put the timeout number immediately after the -z flag, with no space between them.

Remarks

The -n parameter launches the specified library in the kernel process via the intermediary ktux.dll.

The -k, -m,-o, -f, and -a parameters are available only if Kato.dll is present. Kato.dll is the Kato Logging Engine used by most Tux test modules. Tux does not require Kato, but Kato is the recommended logging engine if you want to include logging in your test modules. For more information, see Kato Logging Engine.

A space is not required between a command line parameter and its argument. For example, the following two command lines are equivalent.

tux -t tuxdemo.dll

You must specify each command line parameter separately. For example, the following command line is valid.

tux -b -e

However, the following command line is invalid.

tux –be

See Also

Other Resources

Tux Architecture