This section covers:

Preparation

Before you can start project setup, you need to complete the following actions:

1. Build the C++test Runtime library.
2. Add the library to the linker options. To do so open project properties and go to Parasoft> C++test->Build Settings. On the build settings tab modify the linker options text field by appending existing options with the path to the C++test runtime library
3. If the runtime library was build with support for testing multi threaded applications you need to specify the define -DCPPTEST_THREADS=1 in order to fully enable support for multi-threaded testing.

Building the Test Binary Configuration

Because the test project is not a Wind River Workbench Managed project, there is no support for building it using the standard Build menu items. Building the test binary is done with help of C++test Test Configurations. The following default Test Configurations are available to assist with building the test binary for VxWorks test projects:

• Build VxWorks Test Executable – RTP (PassFS): Generates a “vxe” executable with PassFS used for storing result files.
• Build VxWorks Test Executable – RTP (TSFS): Generates a “vxe” executable with TSFS used for storing result files.
• Build VxWorks Test Executable – RTP (Socket): Generates a “vxe” executable with TCP/IP sockets used for sending results to the host machine.
• Build VxWorks Test Module – DKM (PassFS): Generates an “out” file with PassFS used for storing results.
• Build VxWorks Test Module – DKM (TSFS): Generates an “out” file with TSFS used for storing results.

In some cases, you may need to modify the type of the final test binary produced by the configuration. As a result, it’s helpful to understand how this process is managed and what it can produce. Typical situations are:

• Testing Downloadable Kernel modules
  • The test project can be configured to produce the “*.out” file. The product can be directly started on the target or used in building the VxWorks Image Project (VIP).
  • The test project can be configured to produce the partial image or archive file. The product is usually used as a component in building the VxWorks Image Project (VIP).
• Testing Real Time Process Projects
  
  • The test project can be configured to produce the “vxe” executable file. The product can be directly started on the target or used later with ROMFS projects to build the VxWorks Image Project.

Regardless of which of the above approaches you adopt, you may need to customize the test flow with two main adjustments:

• The toolchain along with symbols extraction utility and its options. This is possible by editing initial properties provided inside the test flow definition. You can choose from the available options according to their comments or specify your own configuration—use the comments as a guide.
• The process of building the project's artifact including linking. See the subsequent paragraphs for more information.

The default linking process is managed by the LinkStep in the test flow definition. It uses the linker executable that is specified in the Project Properties> Build Settings area  and the linker flags scanned during the test project creation (or refreshing). It is important to remember that C++test classifies the last linker command line that appeared during the test project creation/refresh as the valid source of flags; as a result, if the test project was created from more then one build target that contains the linking phase, then only the last one will be used. In such cases, you may need to add additional linker flags in the Project Properties> Build Settings area.  If such a modification is not sufficient, or you need to run more then one process in order to create the final test binary, you may need to provide your own linking step(s) implemented based on the test flow’s CustomStep facility. Typically it may look like in the example below:  

<CustomStep
       id="cust_linking"
       label="Custom linking ..."
       commandLine="valid command line here" 
       workingDir="${cpptest:testware_loc}"
       stdIn=""
       stdOut=""
       result="${cpptest:testware_loc}/resultant_binary" dependencyFiles="${cpptest:test_objects_quoted}"
/ >

 There following test flow variables are useful when implementing a custom linking step:

• ${cpptest:test_object_files} -- comma-separated list of object files that will be part of the test executable.
• ${cpptest:test_objects_quoted} -- space-separated list of object files that will be part of the test executable; each file will be surrounded with quotes (").
• ${cpptest:test_objects_esc_quoted} -- space-separated list of object files that will be part of the test executable; each file will be surrounded with escaped quotes (\").

For more details on the test flow definition syntax see Customizing the Test Execution Flow.

Running the Test Binary

The binary execution process depends on the binary type.

There are 2 Test Configurations designed for running test binaries inside the "Embedded Systems> Wind River> Workbench" category: "Load and Run VxWorks Test Object (DKM)" and "Load and Run VxWorks Test Executable (RTP)". For execution on VxSim, either can be used without modifications, but feel free to customize them as needed. They present messages on the C++test console during execution to remind you about it.