Test Harness Requirements and Limitations

These requirements and limitations apply when you create or use test harnesses, including:

  • The components and actions that support test harnesses

  • The sources that you can use for test harnesses

  • The ports and signals that you can add and use in test harnesses

  • The coverage data you can collect from test harnesses

  • The limitations specific to Subsystem and Subsystem reference blocks

Components that Support Test Harnesses

  • Model blocks

  • Subsystem Reference blocks

  • Subsystem blocks and any block that returns Subsystem from get_param(‘path-to-block’, ‘BlockType’)

  • Reusable library subsystems that have function interfaces and are at the top-level of the library

  • Stateflow® Chart, Truth Table, and State Transition Table blocks

  • System Composer™ components

  • C Caller blocks

  • MATLAB® Function blocks

  • User-defined function blocks

Components and Actions That Do Not Support Test Harnesses

  • Test harnesses are not supported for elements in a Stateflow chart.

  • Test harnesses are not supported for these types of Stateflow objects:

    • Atomic subcharts

    • Simulink-based states

    • Simulink functions

    • MATLAB functions

  • The Upgrade Advisor and XML differencing are not supported for test harness models.

  • You cannot delete a test harness unless all test harnesses are closed.

  • Do not comment out the component under test in the test harness. Commenting out the component under test might cause unexpected behavior.

  • If your test harness contains a To Workspace block, the block variable is not saved in the base workspace after the test case finishes running. Upon test completion, the base workspace is restored to its original state.

Test Harness Sources

  • Signal Editor and Test Sequence sources do not support virtual buses without bus objects.

  • For a test harness with a Test Sequence block or Stateflow chart as the source, all inputs to the component under test must operate with the same sample time.

Ports and Signals

  • The signal names used in the component under test propagate from the model to the test harness. For subsystem harnesses, some propagated signal names might be visible only after you compile the harness. For block diagram harnesses, signal names are propagated even if you do not select Show propagated signals in the Signal Properties dialog box.

  • You cannot add event ports to an existing harness. If you use set_param to add event ports, rebuilding the harness does not retain those added ports.

Subsystem and Subsystem Reference Blocks

  • Test harnesses attached to Subsystem models:

    • Always synchronize with the underlying model

    • Are created without compiling

    • Do not support post-rebuild callbacks (applies to library and subsystem reference harnesses)

    • Do not auto shape inputs

  • If you create a subsystem harness and set its verification mode to software-in-the-loop (SIL), do not also set the Simulation Mode in the System Under Test section of the Simulink Test Manager to Software-in-the-Loop (SIL).

  • If a subsystem has a test harness, you cannot expand the subsystem contents into the model that contains the subsystem. Delete the test harness before expanding the subsystem. For more information, see Expand Subsystem Contents.

  • When you convert a Subsystem or Subsystem Reference block to a Model block, the test harnesses are transferred to the model reference. Harnesses on the Subsystem block are converted to block diagram harnesses. Nested harnesses within the subsystem are copied to identical blocks in the model reference. All transferred harnesses are internal harnesses in the model reference. Test harnesses might be renamed when they are transferred. You can see feedback about the harness transfer in the Complete Conversion pane of the Conversion Advisor or at the MATLAB Command line.

    These limitations apply to converting a Subsystem or Subsystem Reference block to a Model block:

    • SIL and PIL harnesses are not transferred.

    • Requirements in a test harness for a subsystem are not transferred. You must copy them manually.

  • When the test harness is created by compiling the model, the signal dimensions at the harness inputs and outputs are the same as the dimensions of the model. However, this dimension matching might cause conflicts when a subsystem is the only component copied from the model to the harness. To work around the conflicts, change the Simulink® diagnostics VectorMatrixConversionMsg setting to warning or none, instead of error. For information see Vector/matrix block input conversion.

Coverage Collection

  • Loading coverage results to a model, or aggregating coverage results across multiple test runs requires a model consistent with the coverage results. Therefore, to perform aggregated coverage collection, use test harnesses configured to automatically synchronize the component under test. Set Synchronization Mode to Synchronize on harness open and close. For more information, see Synchronize Changes Between Test Harness and Model.

  • If the test harness is configured to synchronize the component under test when you open or close the harness, coverage results from the test harness are associated with the main model. In the Simulink Test Manager, the analyzed model shows as <main_model>/<subsystem> instead of <harness/subsystem>.

  • You can aggregate coverage with additional results collected from the main model, the same test harness, or another synchronized test harness. To aggregate subsystem harness coverage results and main model coverage results, use the Simulink Test Manager because you cannot use the cvdata file and a plus (+) operator.

  • If the component under test design differs between test harness and main model, you cannot aggregate coverage results from the test harness run and the main model run.

  • If the test harness is configured to only synchronize the component under test when you manually push or rebuild, the coverage results are associated with the test harness and cannot be mapped back to the main model. For example, the analyzed model refers to the harness and not the component under test in the main model, and you can only highlight the results on the harness and not on the main model.

See Also

Topics