...
Because VxWorks test objects/relocatables are linked with the -r option, the existence of symbol (function/variable) definitions is not checked, so any symbol resolution errors that occur will not be reported during linking. As a result, you won’t know if you forgot to define these definitions, or made a scope mistake that prevented their inclusion—until the execution phase , when the test object crashes. To receive advance warning about such problems, ensure that the Test Configuration you use for unit testing has the Perform early check for potential linker problems option enabled (in the Execution> Symbols tab) and that it is configured to use the generated external VxWorks image symbols list (as described in Providing an External List of Library Symbols).
...
The following sections in this topic explain how to build the C/C++test Runtime library (in case you want to do this manually for additional control/customization), describe how to generate an external symbols list from your VxWorks image, remind you what Tornado tools must be up and running before you can actually execute your test object, familiarize you with Test Configurations designed specially especially for Tornado testing, and explain how customization of the test flow allows you to adjust the test object as needed to suit the circumstances of embedded testing.
...
- Go to the Runtime Library sources root directory (C++test_install_dir:
<CPPTEST_INSTALL_DIR>/bin/engine/runtime
). Enter the command
make TARGET_CFG:=
followed by eitherWR_egcs_simnt_VxWorks5_4.mk
orWR_gcc2_9_simnt_VxWorks5_5.mk
(depending on your Tornado/VxWorks version).
...
To build the runtime library from the Tornado project or workspace provided with C++test:
- Go to
C++test_install_dir<CPPTEST_INSTALL_DIR>/bin/engine/runtime/
projects
. - Open the appropriate project or workspace. Choose from the ones in
Tornado2_0
orTornado2_2
, depending on your Tornado/VxWorks version. - Build the opened C++testRtLib project.
You can copy and edit any .mk target configuration available in C++test_install_dir<CPPTEST_INSTALL_DIR>/bin/engine/runtime
/target
and provide it for the TARGET_CFG argument. You can also add other Build Targets to Tornado projects to adjust building options and/or change targets.
...
An external symbols list is required to build the VxWorks test object using Test Configuration that have has the Perform early check for potential linker problems option enabled—for example, all built-in Tornado-related Test Configurations. The list should contain all symbols defined in the VxWorks kernel image that you use for running your applications.
...
When we refer to the term "test object" in this section of the user’s guide, we mean the final artifact that is produced from your source files and the test suites, and which must be executed to collect runtime data (such as test case results and coverage data). However, in other parts of the C/C++test User’s Guide, the term "test executable" is used instead. We make this distinction when discussing embedded development because embedded systems don't always support "executables"—the type of binary files that can be called application images , and can be loaded (unpacked) and executed by the system itself. For example, in the case of VxWorks 5.4 and VxWorks 5.5, you can build a full system image that links in your application procedure—or you can build an an incomplete relocatable object that contains symbols from only your application and is linked against a prebuilt system's image at a later time.
In the case of Tornado testing for VxWorks, C/C++test will try to build the second type of objects, which can be best described as "test relocatables," and run them using an original Tornado tool called Tornado Shell (windsh). You will need to have the Tornado Registry (wtxregd) and Target Server (tgtsvr) up and connected with a target running VxWorks prior to launching the runtime testing (see Prerequisites).
...
The default Tornado-shipped version of VxSim has preconfigured support for the Pass Through File System (PassFS) and Target Server File System (TSFS). This support, plus the above setup, enables the test object to be linked against the default version of the Runtime library Library with file communication (see Understanding and Building the Runtime Library) and to use one of the File Systems for transferring results.
...
It’s important for embedded developers to become familiar with the flow of unit testing processing and the chaining of tools that C/C++test applies to the source code. This understanding is crucial for building a robust process that behaves exactly as you expect.
Much of the flow always remains the same across different environments. In most cases, the order and parameters of flow steps shouldn't be altered. However, in certain situations, some critical steps must be adjusted. You can configure test execution flow parameters to suit your specific needs by using an editor in the Test Configuration manager. Usually, there is no need to create a custom version of the execution flow because built-in Test Configurations allow easy editing of the most critical and commonly - modified flow properties.
...
- For all communication modes (file, socket, and rs232), at the end of testing, the results data must always exist in the form of runtime log files stored on the host machine. These will be read by the C/C++test installation on the host.
- With file communication, the Test Object itself generates the runtime log files. Socket/rs communication must involve some listener running on the host that receives and stores the data streamed from the Test Object.
- The TSFS communication is a file communication type for C/C++test. The I/O mechanism is beyond the tool's scope.
- The following steps and attributes may be a subject to review:
- TestRunnerGenerationStep - paths of runtime log files (target's view), attributes: testLogFile, covLogFile
- ReadTestLogStep - a path to Test Log File (host), attribute: testLogFile
- ReadDynamicCoverageStep - a path to Coverage Log File (host), attribute: covLogFile
Debugging Test Cases
C/C++test does not support direct Test Cases debugging for this environment.
...