Please note : This help page is for an older version of Enteprise Archtiect. The latest help can be found here.

Testpoint Management

Testpoint Management provides the facility to test and pass or fail application tasks, viewing test results in real time as the program executes and results are saved.

The image shows a Testpoint run in progress. 

The image shows a Testpoint run in progress. 




See also


You define tests as Class invariants, and as pre/post conditions on operations.

Testpoint design and management is performed on a Test Domain diagram, on which you define constraints and group them into sets, which in turn can form suites.

The Testpoint interface is contextual, and when an object (Class, Test Cut, Test Set, Test Suite) is selected, the constraints for that object are displayed.

In the Testpoint system, the rules that define task behaviors are defined within the model and do not form part of any code base, which has a number of advantages - changing a test condition in other systems can require that the application be re-built; in Enterprise Architect you could stop the run, change a constraint and start the run again without re-building the project.



Test Domain Diagram

A Test Domain diagram is a particular diagram designed for use with the Testpoint facility.

A Test Domain diagram provides specific elements that can aid in the logical composition of the Tests into Test Sets and Suites.

You can perform a Testpoint run on an entire Suite, a single Set or an individual Class.


Test Domain Group

Test Cut

Test Set

Test Suite

Combine Testpoints

Testpoint Class

Test conditions are always defined on a Class; invariants are created for the Class itself, and pre- and post-conditions are defined on its operations.

These conditions can be aggregated later into sets, but the Classes are the building blocks upon which any sets you create are built.




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

The Execution Analyzer uses constraints that you define for a Class and its methods:

A Class invariant is evaluated by the Analyzer whenever a method called on an object of the Class completes
Pre-conditions defined for a method are evaluated when the method is first called; similarly, Post-conditions are evaluated (at the same time as any Class invariant) when the method completes


In the Testpoint facility, constraints are composed using member and local variables in expressions separated by operands; precedence can be achieved through the use of parentheses, which also permits the construction of complex expressions - you can specify any variable that would be in scope at the time.

Elements and members of elements can also form part of the constraint; almost all equivalence operands are supported for primitive types and strings.


Testpoint Editor

Testpoint Constraints

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.

In the Testpoint facility, constraints are composed in much the same way as conditions are written in code; they rely on and are tied ultimately to the named attributes of the Class.

The Execution Analyzer can take a single invariant defined for a Class and test it against every invocation of any method on any instance of that Class; the results can be seen during real time in the Testpoints window


The Testpoints Window

Class Invariant Dialog

Trace Statements

Trace statements are used to output messages during the execution of a program; the Execution Analyzer provides this facility in:

Debugging through the use of Tracepoints and
Testing through the use of Testpoints


In Testpoints, a trace statement can be associated with a pre- or post- condition; whenever the condition is evaluated, the trace statement is output.

You can also group trace statements by level; when you perform a Testpoint run, you can choose the level of trace to be output.

Output can be directed to the Testpoints tab of the Output window or to a file, as configured in the Analyzer script for the parent package.

In debugging, trace statements are associated with code breakpoints.

You can include the values of variables in trace statements, by prefixing the variable name with a special token that lets the debugger know it is not a part of the text; the available tokens are:

$ - when the variable is to be interpreted or printed as a string
@ - when the variable is a primitive type (int, double, char)


Variables can be qualified - that is, the members of a variable can be printed.

You separate member names with a period character ('.')

The value of the station name = $
Departing passenger count = @passenger.count









The Output Window

Managing Scripts

Learning Center topics

(Alt+F1) | Execution Analysis | Testpoints | Introducing Testpoints