Book a Demo

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

Prev Next

Testpoints

Testpoints present a scheme by which constraints and rules governing the behavior of objects can be taken from the model and applied to one or more applications. The advantages that schemes such as this offer are tolerance to code changes - adding and subtracting lines from a function has no effect on the constraints that govern it. Another advantage is that changes to the behavioral rules do not require a corresponding change to any source code; meaning nothing has to be re-compiled!

Also, the ability to verify multiple applications using a single test domain is a simple rather than onerous matter. The Test Domain is a both a logical and relational model; constraints in the Class model can be partitioned with Test Cuts. These can be aggregated simply into Test Sets and Test Suites using connectors. Due to the decoupling of the Test Domain from the codebase, it is a simple choice of buttons to run a program normally, or run it for a specific Test Domain. This system also delivers practical benefits in that no instrumentation is required at all. Test results are displayed in the report window during the run, in real-time, as the program runs. These results can be retained, and reviewed at any time in the 'Test Details' dialog or using Enterprise Architect's documentation features.

The image below shows the rich tapestry of features available in Enterprise Architect's test domain model, a dynamic medium providing runtime visualization of test case execution

Features

Feature

Details

See also

Testpoint Composition

Testpoint composition is performed using the Testpoints window. The Testpoints window is context-sensitive and displays the Test Domain for the selected element in either the Browser window or diagram. Selecting a single Class will display the Class structure. A 'pencil' icon is displayed against Classes and methods that have existing constraints.

When you select a Test Cut, Set or Suite Test, the Testpoints window displays the entire Domain structure, including all the Classes that make up the domain. Note: You can navigate the domain hierarchy using the 'Navigation' pane on the right. Testpoints are composed as expressions, using the variable names of the Class members. The Intelli-sense shortcut Ctrl+Space is available within the editor to help you find these. Expressions that evaluate to True are taken to mean a pass. Returning False is taken to mean a fail.

The image below shows results from a process running under a test domain in Enterprise Architect

You can add or edit an existing Invariant by double-clicking the Class.

You can add or edit an existing pre- or post-condition similarly by double-clicking the method.

Double-clicking a Testpoint will automatically display the source code if it is available.

Line conditions are best added from within the code editor using its shortcut menus.

This image is of a pre-condition in the Test domain.

An example of composing a precondition in Enterprise Architects Test Domain system.
The Testpoints Window Testpoint Editor

Testpoint Trace Statements

Each Testpoint can have its own Trace statement. The Trace statement is a dynamic message that can reference variables in its object or local scope. They are output during the evaluation of a test. They can be configured to be output every time a constraint is evaluated, or more usually when a test has failed. Trace statements can be directed to the 'Testpoints' tab of the System Output window, or to an external file. You can configure this in any Analyzer Script.

Trace Statements The System Output Window Managing Analyzer Scripts

Test Domain Composition

The Test Domain diagram is a dynamic medium where Testpoints are assembled to test Use Cases. Use Cases in a Test Domain diagram are provided in three different stereotypes: Test Cut, Test Set and Test Suite. Management of the domain is as easy as modeling on any diagram. The toolbox and shortcut menus provide access to any Test Domain Artifacts. In brief, Testpoints from multiple Classes are aggregated into Test Sets. Test Sets are then linked to form Test Suites. Both Test Cuts and Test Sets are re-usable assets. Linking the same Test Set to the one or more Test Suites is a matter of drawing connectors.

Test Domain diagram defining tests and test sets in Sparx Systems Enterprise Architect.

Test Domain Toolbox Test Cut Test Set Test Suite Test Domain Diagram

Test Domain and the Class Model

Rarely would a Use Case involve all the methods of a single Class. Most likely it is realized using a variety of methods from collaborating Classes. We call this subset of methods a 'cut', and the Test Cut Artifact is the tool we use to make these cuts. The Testpoints window will adapt depending on the context, to be that for a Test Domain or Class element. This image shows the Testpoints window when a Test Cut has been selected. Note the checkboxes, which are only visible for a Test Cut. They denote the methods (Test Cuts) that are contributing to a Test Set. In this example the Test domain was generated by the Execution Analyzer, which did the method identification work for us.

Aggregating test cases across multiple classes to create a Testcut that take part in any Enterprise Architect Test Domain

Testpoint Evaluation

The Testpoints window is used to evaluate Test domains. The window has a toolbar for starting or attaching to the target application. The domain to test is always reflected by the element that has context, so if you select a Class the window will show only the Class structure and Testpoints of that Class. If you select a Test Suite, the window will display the entire domain hierarchy and all the Testpoints included in it. Clicking on the Run button will load the Testpoint domain in the Execution Analyzer, which will then evaluate, collect and update the report window as Use Cases pass or fail each test. The exact details of each constraint type and the when and how of that constraint's capture are:

  • A Class Invariant is evaluated by the Analyzer whenever any method called on an object of this Class type is completed; the invariant serves to test that the state of a complying object is both known and permitted
  • 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 if and when their specific line of code comes into scope during program execution
Testpoint Constraints