For information about supported Green Hills compilers, see Compilers.
Green Hills INTEGRITY project integration is provided by BDF creation/import - see Importing INTEGRITY Projects for Unit Testing or Application Monitoring.
C++test can test Dynamic Download INTEGRITY Application Projects that are loaded onto an INTEGRITY kernel (specified by the user). The chosen virtual address space (VAS) to be tested can be run with unit testing or application monitoring. C++test supports automated testing of VAS projects in isolation, therefore some manual modifications to the integrate (.int) file may be necessary if the original project has many virtual address spaces and if those virtual address spaces interact with each other.
C++test enables testing of Green Hills MULTI projects for INTEGRITY applications by supporting the following C/C++ compilers:
The following components are provided to facilitate testing Green Hills MULTI projects:
The following properties are available in Green Hills INTEGRITY test configurations:
C:\ghs\int1104\bin\sim800\kernel by default:binDir=bin as one of the flags to the project. This argument will ensure that your original project artifacts will not interfere with C++test's automation. C++test runs commands with your project directory as the working directory, so build artifacts that are left there can cause unwanted results when building test executables. .int file to bring up the Integrate GUI.For gpj projects:
cpptesttrace --cpptesttraceProjectName=<VAS_name> --cpptesttraceOutputFile="<dir>\vas.bdf" gbuild -all -top <top_prj_name>.gpj <VAS_name>.gpj |
For Make projects:
cpptesttrace --cpptesttraceProjectName=<VAS_name> --cpptesttraceOutputFile="<dir>\vas.bdf" make <target_for_chosen_VAS> |
-lhostio and -intfile=<path_to_integrate_file> to the Linker options field in the Options section. C++test requires linking with hostio libraries to use fopen() for writing unit test and coverage data to logs. intfile file is the single-VAS .int file for your INTEGRITY application; it forces the integration step to occur after the linking step is complete.#include "INTEGRITY.h. When using auto-generated stubs, the INTEGRITY.h header file is usually required.grunBy default, the kernel specified in the test configuration properties is started using grun, which is a command used for running debug servers. The grun command is executed with a default timeout of 180 seconds. This stops the kernel in a predictable manner for cases in which the test execution results in erroneous behavior. If you find that you need longer than this 180 seconds for test execution, then you can modify the test execution flow by changing the value attribute for the dbserv_timeout (<SetProperty key="dbserv_timeout" value="180" />) property or by disabling grun.
To disable grun uncomment the following line located inside the test execution flow editor to run the specified kernel using the debug server directly:
<!--SetProperty key="kernel_cmd" value="${cpptestproperty:dbserv} "${cpptestproperty:kernel}"" /→Comment the following line located inside the test execution flow editor to disable grun for kernal execution.
<SetProperty key="kernel_cmd" value="grun
${cpptestproperty:dbserv_timeout_opt} ${cpptestproperty:script_opt}
${cpptestproperty:dbserv} -- "${cpptestproperty:kernel}"" /> |
Regardless of the method chosen for running the kernel, the test execution flow will still attempt to kill any kernel process that maybe running when the test execution is completed.
In order for the test execution flow to know that a test execution is finished running, a file synchronization step is employed, which can be found toward the bottom of the test execution flow:
<FileSynchronizeStep
fileSync="${cpptest:testware_loc}/cpptest_results.tlog"
fileInactiveTimeout="10000"
/> |
This step tracks the timestamp of the test log file. The test log file is updated with information about every test as they are executed. C++test stops the execution if it detects that the log file has been inactive for 10000 milliseconds. If you expect periods of inactivity in your unit tests that might exceed 10 seconds, you should increase the value of the fileInactiveTimeout attribute to the desired timeout value. For more information on the FileSynchronizeStep flow step and other information about test flow execution, see Test Flow Descriptions and Examples.
The file synchronization method may not be sufficient for proper test execution flow when running application monitoring using the Run GHS INTEGRITY Application with Mem Monitoring test configuration. If your application contains few reportable memory violations, the results file may be updated to infrequently, which may lead to an unwanted timeout.
In addition to increasing the time-to-timeout, you can use an alternative functionality of the FileSynchronizeStep that forces C++test to wait for the generation of the synchronization file to signal the end of application execution:
<FileSynchronizeStep fileSync="<path/to/synchronization/file.txt>" timeout="30000" /> |
This synchronization file can either be created manually from inside your application's code, or you can provide an implementation of the CppTest_Finalize function to manually write a file the FileSynchronizeStep will wait for. The CppTest_Finalize function is automatically called as one of the final steps of application execution.
After creating the synchronization file, you can increase the timeout to a value that is sufficient for the duration of your application's running time. For more information about custom initialization and finalization, see Initialization and Finalization.
Calls to Exit() may need to stubbed out in order to prevent premature completion of test execution, if such calls are used within tested functions. If necessary, you can still call Exit() by implementing the CppTest_Finalize function, which is automatically called as one of the final steps of application execution. For more information about custom initialization and finalization, see Initialization and Finalization.
Many C++test test configurations use a mechanism that enables automatic rerunning of test executables after unexpected behavior in an individual test case causes the test executable to crash or abort. This mechanism will rerun the test executable beginning with the next unrun unit test. However, due to limitations in the Green Hills framework for INTEGRITY applications, this mechanism is unavailable when testing INTEGRITY applications. If a unit test causes a premature end to test execution, unit testing will end and results collected up to that point will be available.
While C++test works best when testing a single VAS in isolation, it may be the case where the tested VAS requires interaction with another VAS in the same INTEGRITY application. In this case, some manual customization to the workflow will be necessary. Consider the following :
The C++test runtime relies on calls to destructors of static objects for some necessary finalization steps during test execution and application monitoring. Due to a current limitation in the Green Hills MULTI v6.1.x C/C++ compiler v2013.1.x for INTEGRITY on PowerPC, destructors for static objects will not be called if the -non_shared flag is not used in your project. If you are not using the -non_shared compiler flag, you will need to manually insert a call to the CppTest_FinalizeRuntime() function at the end of your application's main() function. This will allow C++test to do all necessary finalization steps. For additional information about how to use the CppTest_FinalizeRuntime() function, see Initialization and Finalization.