Test Domain Diagram

The Test Domain diagram is the medium where you assemble and group test cases for a particular domain. An example of a Test domain might be 'Customer'. The breadth and depth of the domains you assemble is up to you. You might have separate domains for 'Add Customer' and 'Delete Customer', depending entirely on how you consider best to balance the domain hierarchy. The Diagram Toolbox and Shortcut menu provide a number of Artifacts to help model the domain. Because the medium is dynamic, allowing you to revisit and build on relationships between Test domains, the system is a great model for delivering reusable assets to a organization that are low overhead and integrate with both the UML view of the world, and the Software Engineering nuts and bolts of daily life.

Facilities

Facility	Details	See also
Test Domain Generation	If you think the process of composing a Test Domain is complex, it can be, but help is at hand! The Execution Analyzer can produce a Test Domain diagram for you. It cannot write the Tests for you, but it can do some of the leg work. It can identify the Classes and pick out only those methods that participated in a Use Case. And this is not guesswork. The Analyzer Test Domain is obtained from a running program. This image shows the Test Domain generated by the Execution Analyzer from recording an Example Model program. And this is the recording itself (as a Sequence diagram) from which the Test Domain was generated.	Recording Sequence Diagrams Recorder Toolbar The Testpoints Window
Test Domain Composition	The first task on a Test Domain diagram is to create the Use Cases (Test Sets). These define this particular domain's responsibility. The Diagram Toolbox and shortcut menu provide Artifacts to help you achieve this. The first of these elements is the Test Cut, which is used in the next step; identifying those methods (from the Class model) that you consider to be participants in the Use Case. The Test Cut Artifact is useful because it allows us to partition a Class, selecting only those methods that are relevant. Test Cuts can be run individually or linked to one or more Test Sets. Test Sets in turn can be linked to one or more Test Suites. In any case, any element of the Test domain tree can be run individually or as a whole.	Test Domain Toolbox Test Cut Test Set Test Suite The Testpoints Window

Facility

Details

See also

Test Domain Generation

If you think the process of composing a Test Domain is complex, it can be, but help is at hand! The Execution Analyzer can produce a Test Domain diagram for you. It cannot write the Tests for you, but it can do some of the leg work. It can identify the Classes and pick out only those methods that participated in a Use Case. And this is not guesswork. The Analyzer Test Domain is obtained from a running program. This image shows the Test Domain generated by the Execution Analyzer from recording an Example Model program.

And this is the recording itself (as a Sequence diagram) from which the Test Domain was generated.

Recording Sequence Diagrams Recorder Toolbar The Testpoints Window

Test Domain Composition

The first task on a Test Domain diagram is to create the Use Cases (Test Sets). These define this particular domain's responsibility. The Diagram Toolbox and shortcut menu provide Artifacts to help you achieve this. The first of these elements is the Test Cut, which is used in the next step; identifying those methods (from the Class model) that you consider to be participants in the Use Case. The Test Cut Artifact is useful because it allows us to partition a Class, selecting only those methods that are relevant. Test Cuts can be run individually or linked to one or more Test Sets. Test Sets in turn can be linked to one or more Test Suites. In any case, any element of the Test domain tree can be run individually or as a whole.

Test Domain Toolbox Test Cut Test Set Test Suite The Testpoints Window