Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

Testpoint Management

Testpoints define constraints that are applied to Classes and Operations, ensuring that a system is behaving as expected during runtime. Testpoints are evaluated during a debugging session and the result of each evaluation is recorded as either a Pass or Fail. Test results can be viewed from the Testpoints Window in real-time as the program is executed. After a test run has completed, the recorded results can be saved for later reference.

VEA-TestpointRun

Topics

Topic

Detail

See also

Overview

Testpoint design and management is performed using the Test Domain diagram and Toolbox. Testpoints are defined on Classes and Operations, which can be refined into Test Cuts, then grouped into Test Sets and Test Suites.

Testpoints define Constraints. These can be Invariant constraints on Classes, or Pre-condition, Post-Condition and Line-Condition constraints on Operations.

Constraints are defined and executed using the Testpoint Window. The Testpoint Window is context-sensitive based upon the currently selected item in the Project Browser or Diagram View.

Testpoints are defined within the model and do not make any changes to your application source code. This makes it possible to quickly edit a testpoint constraint at any time and restart the test run without needing to re-build the application.

The Testpoints Window

Testpoint Editor

Test Domain Diagram and Toolbox

The Test Domain diagram and toolbox allow definition of Test Cut, Test Set and Test Suite objects to aid in the logical composition of tests.

Testpoints are always defined on Classes and Operations, but can be filtered and aggregated into logical Test Cuts and Test Sets.

A Testpoint run can be performed for on an individual Class, a single Test Set, or an entire Test Suite.

Constraints

The Testpoint facility is based on a programming-by-contract model.

When executing a test run, the Execution Analyzer evaluates constraints defined for Classes and Operations:

•

A Class Invariant is evaluated by the Analyzer whenever any method called on an object of this Class type is completed. An invariant defines the rules or constraints of a Class; it is expected that no objects of the Class nor its methods can break this constraint, thus preserving the state of the object.

•	Pre-conditions are evaluated immediately before an operation is called. Post-conditions are evaluated (at the same time as a Class invariant) when the method is completed. Line-conditions are evaluated only when a specific line of source code is reached during execution.

Testpoint constraints are composed using member and local variables in logical expressions which return either a true or false result. Any Local and Member variables referenced by a constraint must be in scope at the time the expression is evaluated.

Constraint Composition

Trace Statements

When defining a Testpoint, an optional Trace Statement can also be specified. A Trace Statement is a message that is output during execution of a debug session. The Trace Statement Level can be configured to either output every time the constraint is evaluated, or only when the constraint condition has failed.

Output from a Testpoint trace statement can either be directed to the Testpoints tab of the Output Window, or to an external file, as configured in the Analyzer Script for the parent package.

Specifying a Trace Statement

The System Output Window

Managing Analyzer Scripts

Learning Center topics