...

• • • The C/C++ Code Coverage metrics section allows you to select the type of coverage metric(s). The Line hit count option determines whether the number of line hits is calculated. For additional information about types of metrics, see Understanding Coverage Types.
    • Select the Enablecoverage for C++ templates option to enable the collection of code coverage information from C++ templates. See Support for Template Functions.

    • Select the Optimize coverage (Application Monitoring Only) option to enable special optimized coverage modes, which are described in the following table:

      Option	Purpose
      Coverage instrumentation> Size optimized	The memory buffers used by coverage instrumentation for storing metrics data are optimized to take the lowest possible amount of RAM. This mode is suitable for embedded devices withlimitedamount of memory.
      Coverage instrumentation> Speed optimized	The memory buffers used by code coverage instrumentation for storing metrics data are optimized to assure the lowest possible execution time overhead. This mode is suitable for measuring coverage on application withlowtolerance for additional execution time overhead.
      Enable data consistency check	This option enables additional algorithms for detecting coverage buffer corruptions. Enable this option if coverage buffer corruption is likely caused by faulty behavior in the application under test. Enabling this option imposes some additional execution time overhead.
      Enable initialization of the coverage memory buffer	This option enforces the initialization of memory buffers used by code coverage instrumentation. This option should be selected if your compiler does not initialize global and static variables to 0 before the program begins running (required by ISO C standard). This option is enabled automatically (and can not beunabled) if "Size optimized" coverage instrumentation mode and "Enable data consistency check" are enabled simultaneously.

    • Enable enum data autogeneration: Determines whether enum data required by enumeration-related API macros is collected (see Handling Enum Values for details). Execution details> Test execution flow: Determines whether

      Info
      icon false title Customizing the test execution flow
      When you run a Test Configuration set to execute tests, C++test

      uses the default flow for host-based unit testing, for building a test executable (e.g., for trial builds without execution), for generating stubs for missing function and variable definitions, or a custom flow (e.g., for embedded or other cross-platform testing). Details on defining a custom flow are discussed in Customizing the Test Execution Flow.

      performs a series of actions which usually leads to the unit testing results being loaded into the C++test UI. These actions are defined in a test flow file, which is stored in XML format and saved as part of the Test Configuration, which makes it possible to share it across the team.  C++test provides a default execution flow that is designed specifically for host-based testing. C++test also allows you to define a custom test flow which can include C++test internal actions or external utilities started as processes in the operating system. The default test flow can be modified by:      •  Customizing the parameters of existing steps - see Customizing the Test Execution Flow      •  Removing existing steps      •  Adding new steps To define a custom test flow:      1. Open the Test Configurations panel by choosing Parasoft> Test Configurations.      2. Select the Test Configuration that you plan to use for test execution.
      Info
      icon false title Customizing the test execution flow
      When you run a Test Configuration set to execute tests, C++test performs a series of actions which usually leads to the unit testing results being loaded into the C++test UI. These actions are defined in a test flow file, which is stored in XML format and saved as part of the Test Configuration, which makes it possible to share it across the team.  C++test provides a default execution flow that is designed specifically for host-based testing. C++test also allows you to define a custom test flow which can include C++test internal actions or external utilities started as processes in the operating system. The default test flow can be modified by:      •  Customizing the parameters of existing steps - see Customizing the Test Execution Flow      •  Removing existing steps      •  Adding new steps To define a custom test flow:      1. Open the Test Configurations panel by choosing Parasoft> Test Configurations.      2. Select the Test Configuration that you plan to use for test execution.      3. Open the Execution> General tab.      4. Click the Edit button      5. Enter your modified test flow or adapt existing one              •  If you want to adapt an existing test flow, choose that test flow from the Available built-in test execution flow(s) box, then click Restore. The XML for that test flow will  then be displayed, and can be edited as needed.      6. Click OK to save the modified file.

• Execution details> Test execution flow: Determines whether C++test uses the default flow for host-based unit testing, for building a test executable (e.g., for trial builds without execution), for generating stubs for missing function and variable definitions, or a custom flow (e.g., for embedded or other cross-platform testing). Details on defining a custom flow are discussed in Customizing the Test Execution Flow.

• Execution details> Quick execution mode: Configures C++test to be less strict when verifying whether the test executable subproducts are current (e.g., whether they have changed since the previous run).

  Tip
  title Tip: When to use Quick Execution Mode
  "Quick execution mode" can be used to reduce the time required to prepare the test executable. Since C++test will be less strict when verifying whether the test executable subproducts are current, the test preparation phase is faster. In this mode, C++test assumes that the following have not been modified since the previous run:    •  Compiler and linker options.    •  Header files.    •  Stub configuration. We recommended using the quick execution mode as follows:    1. Create a "quick" execution Test Configuration by duplicating a Test Configuration with the "normal" mode, and then enabling the Quick execution mode checkbox.    2. Use the two Test Configurations as follows:            •  When running tests on the server machine (nightly tests), use the "normal" Test Configuration.            •  When running tests on the developer machine (daily work), use "quick" Test Configuration. Normal execution mode is required on the developer machine when:    •  Compiler / linker flags in the project have changed (e.g., a new macro definition was added to the compiler options or a new external library was added to the list of the linker flags).    •  One of the header files included by the tested source / test suite source / stubs source was modified.    •  A new user stub was added to the project.    •  A stub definition was removed from the project.    •  Coverage data needs to be reported. After you use the  "normal" configuration to re-build the test-executable, you can return to the "quick" mode.

• Unit Testing> Test suite file search patterns: Determines where C++test looks for test suite files to be executed in the current test. To specify multiple locations (for instance, if you have different tests for different levels of testing or for host vs. target),  enter a semicolon before each additional location.
  • • • The following variables are supported (examples are based on a tested file /MyProject/module1/src/MyClass.cpp)
        • ${source_name} - Full name of the tested file (MyClass.cpp)
        • ${source_base_name} - Base name of the tested file (MyClass)
        • ${source_ext} - Extension of the tested file (cpp)
        • ${source_loc} - Workspace-oriented location of the tested file (/MyProject/module1/src)
        • ${source_loc_rel} - Project relative location of the tested file (module1/src)
        • ${source_loc_rel:<path>} - <path> Relative location of the tested file (src, for <path>=/MyProject/module1)

        • ${test_ext} - C++test specific extension of a test suite file (.cpp)

          
          

          Conditional Content
          IDE: (Eclipse) IDE: (Eclipse) sv-attr:0A0102040159A975064F0FA35093CF15 0A0102040159A981DDF9EE0F6AC657B2
          •  ${project_loc} - The path to the Eclipse project location (the location that contains the .project file). Do not use this variable if your project has "linked" source folders—source files that do not actually live within your project location.

          Conditional Content
          IDE: (Eclipse) IDE: (Eclipse) sv-attr:0A0102040159A975064F0FA35093CF15 0A0102040159A981DDF9EE0F6AC657B2
          •  ${resource_loc} - The path to the specific project resource. For instance, ${resource_loc:/MyProject/linked_src_dir/source.cpp} will be resolved into C:\src\source.cpp. You can use this variable if your project has "linked" source folders—source files that do not actually live within your project location. For example: Do not use this variable if your project has "linked" source folders—source files that do not actually live within your project location.

        • Test suites must be available from the project tree.

          Conditional Content
          IDE: (Eclipse) IDE: (Eclipse) sv-attr:0A0102040159A975064F0FA35093CF15 0A0102040159A981DDF9EE0F6AC657B2
          If you do not want to store your tests within the project directory, you can add a folder that links to files stored else-where in your file system. To do this:    •  Choose File> New> Folder (if this is not available, choose File> New> Other, select General> Folder, then click Next).    •  Click the Advanced button.    •  Enable the Link to folder in file system option.    •  Enter or browse to the location of your source files.    •  Click Finish.

• Unit Testing> Create separate test executable for each tested context: Determines whether C++test uses a separate test executable for each tested context (e.g., file).
  • • If this option is enabled, C++test will create and execute a separate executable for each source file (but it will still use additional project sources and stubs as defined on the Symbols tab). An additional test executable will be prepared and run for all tests that do not have CPPTEST_CONTEXT set. If you prefer smaller test executables, enable this option.
    • If this option is disabled and the complete project is selected for unit test execution, C++test will build one large executable with all of the source files and run it once.

Symbols tab

Anchor
Symbols_tab Symbols_tab

...