Testpoint Management

Overview

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.

Constraints

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:

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:

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:

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 = $station.name
Departing passenger count = @passenger.count

The Output Window

Managing Scripts