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 example was produced using the Example Model that ships with Enterprise Architect

The image shows a Testpoint run in progress. The example was produced using the Example Model that ships with Enterprise Architect

Topics:

Topic

Detail

See also

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:

  • 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 ('.'); for example:

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

 

 

 

 

 

 

 

The Output Window

Managing Scripts

Learning Center topics:

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