Tux Command-Line Parameters (Windows CE 5.0)

Send Feedback

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 CETK server. The Tux client is a console application and uses the following syntax.

tux [-b] [-e] [-sfile_name | -dtest_dll] [-cparameters] [-rseed]
[-xtest_case] [-l | -lv] [-taddress] [-h] [-kaddress] [-m] [-o] [-ffile_name] [-a] [-ztimeout]

The following table shows the Tux parameters.

tux -x10,12,15-20

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

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

Parameters

• -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.

• -s file_name
  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 Microsoft Windows CE, suite files can reside on the Windows 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 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.

• -c parameters
  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.

• -r seed
  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.

• -x test_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.

• -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.

• -ffile_name
  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 CE, you can prefix the file name with cesh: if you want to create the file on 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 -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
tux -ttuxdemo.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

Kato Logging Engine | Tux Architecture

Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.