| /a | AUTORUN | Autorun (REG_SZ) | When set to one (1), the device automatically starts the test after the connection is established. |
| /s | DEFAULTSUITE | DefaultSuite (REG_SZ) | Specifies the name of the default test suite to run. |
| /x | AUTOEXIT | Autoexit (REG_SZ) | When set to one (1), the application automatically exits when the tests are completed. |
| /d | DRIVERDETECT | DriverDetect (REG_SZ) | When set to zero (0), the detection of devices drivers is disabled. |
Running CETK Tests in Standalone Mode
Clientside.exe connects to CETest.exe on the developer workstation, yet it is also possible to run CETK tests without a connection, which is particularly useful for devices that provide no connectivity possibilities. If you include the Windows Embedded CE Test Kit catalog item in the run-time image, you can start the test engine (Tux.exe) directly, which implicitly starts the Kato logging engine (Kato.exe) to track the test results in log files. For example, to perform mouse tests (mousetest.dll) and track the results in a file called test_results.log, you can use the following command line:
Tux.exe -o -d mousetest -f test_results.log
For a complete list of Tux.exe command-line parameters, see the section 'Tux Command-Line Parameters' in the Windows Embedded CE 6.0 Documentation, available on the Microsoft MSDN Web site at
Creating a Custom CETK Test Solution
The CETK includes a large number of tests, yet the default tests cannot cover all testing requirements, especially if you added your own custom device drivers to a BSP. To provide you with an option to implement user- defined tests for your custom drivers, the CETK relies on the Tux framework. Platform Builder includes a WCE TUX DLL template to create a skeleton Tux module with a few mouse clicks. When implementing the logic to exercise your driver, you might find it useful to check out the source code of existing test implementations. The CETK includes source code, which you can install as part of the Windows Embedded CE Shared Source in the Setup wizard for Windows Embedded CE. The default location is %_WINCEROOT%PrivateTest.
Creating a Custom Tux Module
To create a custom test library that is compliant with the Tux framework, start the Windows Embedded CE Subproject Wizard by adding a subproject to the OS design of your run-time image and select the WCE TUX DLL template. This causes the Tux wizard to create a skeleton that you can customize according to your driver requirements.
You must edit the following files in the subproject to customize the skeleton Tux module:
¦ Header file Ft.h Defines the TUX Function Table (TFT), including a function table header and function table entries. The function table entries associate test IDs with the functions that contain the test logic.
¦ Source code file Test.cpp Contains the test functions. The skeleton Tux module includes a single TestProc function that you can use as reference to add custom tests to the Tux DLL. You can replace the sample code to load and exercise your custom driver, log activities through Kato, and return an appropriate status code back to the Tux test engine when the tests are completed.
Defining a Custom Test in the CETK Test Application
The skeleton Tux module is fully functional, so you can compile the solution and build the run-time image even without code modifications. To run the new test function on a target device, you must configure a user-defined test in the CETK workstation server application. For this purpose, CETK includes a User-Defined Test Wizard, which you can start by clicking the User Defined command on the Tests menu. Figure 4-12 shows the User-Defined Test Wizard with configuration parameters to run a skeleton Tux module.
Figure 4-12 Configuring a custom test in the User-Defined Test Wizard
Debugging a Custom Test
Because Tux tests rely on code and logic implemented in Tux DLLs, it might be necessary to debug the test code. One issue worth mentioning is that you can set breakpoints in your test routines, but when code execution halts on those breakpoints, you lose the connection between the client-side application (Clientside.exe) and the workstation server application (CETest.exe). Consider using debug messages instead of breakpoints. If you must
