Arcade Game Maker Pedagogical Product Line: Velocity/Direction/Speed Cluster Test Plan
Introduction
This is the test plan for the Velocity/Direction/Speed cluster of classes. The basic classes in this cluster support the animation of movable sprites.
The Arcade Game Maker (AGM) product line organization based its test plans on the Institute of Electrical and Electronics Engineers (IEEE) 829 standard.
Cluster users should report any errors to John D. McGregor, cluster owner.
Test Items
This plan tests the Velocity, Direction, and Speed classes. These classes are tested together because they form a tightly coupled cluster. The Direction and Speed classes are primitive and require math functions only from the underlying language library. The Velocity class uses instances of the Direction and Speed classes as shown in the following figure.
Cluster
Tested Features
The tested features are described in terms of Velocity. The Speed and Direction classes will be tested only to the extent that they are required to support Velocity. If they are used later without Velocity, additional testing will be required. The following table shows the three increments for developing the cluster. Functionality will be tested in the order shown.
| Development Increments | ||
| Increment | Functionality | Schedule |
| 1 | Define the basic functionality for
Velocity. Complete the functionality for Direction and Speed. |
|
| 2 | Revise Speed and Direction. Implement complete Velocity interface. |
|
| 3 | Optimize the cluster. | |
Features Not Tested (Per Cycle)
All features of Velocity will be tested during this cycle. Velocity is fundamental to correcting Sprite movement.
Testing Strategy and Approach
Syntax
The unit test cases are written in C#, as is the product code.
Description of Functionality
The Speed and Direction classes are simple encapsulation classes that hold a value and provide access to it. As such, a few basic values are used as shown in the following table.
| Variables Involved in Tests | ||
| Variable | Type | Constraints |
| Speed | Integer | None |
| Direction | Integer | 0<=direction<=360 |
The following two tables show the analysis of data types used in Speed and Direction. Because Velocity is a combination of the Speed and Direction classes, its test table (shown in the following table) is constructed from Speed and Direction.
A negative speed is not possible, but the class does not prevent negative values (an optimization decision).
A default constructor must also be tested.
| Speed Class | |
| Test # | Speed Value |
| 1 | 5 |
| 2 | 0 |
| 3 | -5 |
| 4 | Not entered |
| Direction Class | |
| Test # | Direction Value |
| 1 | 0 |
| 2 | 360 |
| 3 | 27 |
| 4 | 90 |
| 5 | 410 |
| 6 | Nothing |
| Velocity Test Value Combinations | |||
| Test # | Speed Value | Direction Value | Expected Result |
| 1 | 5 | 0 | |
| 2 | 5 | 360 | |
| 3 | 5 | 27 | |
| 4 | 5 | 90 | |
| 5 | 5 | 410 | |
| 6 | 0 | 0 | |
| 7 | 0 | 360 | |
| 8 | 0 | 27 | |
| 9 | 0 | 90 | |
| 10 | 0 | 410 | |
| 11 | -5 | 0 | |
| 12 | -5 | 360 | |
| 13 | -5 | 27 | |
| 14 | -5 | 90 | |
| 15 | -5 | 410 | |
Expected Output
The output will vary for different tests. The next 5 tables provide the expected output for each method in the class. For Set/Get Direction, a default constructor must also be tested.
| Set/Get Direction | |||
| Test # | Speed Value | Direction Value | Expected Result |
| 1 | 5 | 0 | 0 |
| 2 | 5 | 360 | 0 |
| 3 | 5 | 27 | 27 |
| 4 | 5 | 90 | 90 |
| 5 | 5 | 410 | 50 |
| 6 | 0 | 0 | 0 |
| 7 | 0 | 360 | 0 |
| 8 | 0 | 27 | 27 |
| 9 | 0 | 90 | 90 |
| 10 | 0 | 410 | 50 |
| 11 | -5 | 0 | 0 |
| 12 | -5 | 360 | 0 |
| 13 | -5 | 27 | 27 |
| 14 | -5 | 90 | 90 |
| 15 | -5 | 410 | 50 |
| SpeedX | |||
| Test # | Speed Value | Direction Value | Expected Result |
| 1 | 5 | 0 | 5 |
| 2 | 5 | 360 | 5 |
| 3 | 5 | 27 | 4 |
| 4 | 5 | 90 | 0 |
| 5 | 5 | 410 | 3 |
| 6 | 0 | 0 | 0 |
| 7 | 0 | 360 | 0 |
| 8 | 0 | 27 | 0 |
| 9 | 0 | 90 | 0 |
| 10 | 0 | 410 | 0 |
| 11 | -5 | 0 | -5 |
| 12 | -5 | 360 | -5 |
| 13 | -5 | 27 | -4 |
| 14 | -5 | 90 | 0 |
| 15 | -5 | 410 | -3 |
| SpeedY | |||
| Test # | Speed Value | Direction Value | Expected Result |
| 1 | 5 | 0 | 0 |
| 2 | 5 | 360 | 0 |
| 3 | 5 | 27 | 2 |
| 4 | 5 | 90 | 5 |
| 5 | 5 | 410 | 3 |
| 6 | 0 | 0 | 0 |
| 7 | 0 | 360 | 0 |
| 8 | 0 | 27 | 0 |
| 9 | 0 | 90 | 0 |
| 10 | 0 | 410 | 0 |
| 11 | -5 | 0 | 0 |
| 12 | -5 | 360 | 0 |
| 13 | -5 | 27 | -2 |
| 14 | -5 | 90 | -5 |
| 15 | -5 | 410 | -3 |
| isHeadingUp | |||
| Test # | Speed Value | Direction Value | Expected Result |
| 1 | 5 | 0 | False |
| 2 | 5 | 360 | False |
| 3 | 5 | 27 | False |
| 4 | 5 | 90 | False |
| 5 | 5 | 410 | False |
| 6 | 0 | 0 | False |
| 7 | 0 | 360 | False |
| 8 | 0 | 27 | False |
| 9 | 0 | 90 | False |
| 10 | 0 | 410 | False |
| 11 | -5 | 0 | False |
| 12 | -5 | 360 | False |
| 13 | -5 | 27 | True |
| 14 | -5 | 90 | True |
| 15 | -5 | 410 | True |
| isHeadingDown | |||
| Test # | Speed Value | Direction Value | Expected Result |
| 1 | 5 | 0 | False |
| 2 | 5 | 360 | False |
| 3 | 5 | 27 | True |
| 4 | 5 | 90 | True |
| 5 | 5 | 410 | True |
| 6 | 0 | 0 | False |
| 7 | 0 | 360 | False |
| 8 | 0 | 27 | False |
| 9 | 0 | 90 | False |
| 10 | 0 | 410 | False |
| 11 | -5 | 0 | False |
| 12 | -5 | 360 | False |
| 13 | -5 | 27 | False |
| 14 | -5 | 90 | False |
| 15 | -5 | 410 | False |
Specific Exclusions
There are no specific exclusions.
Dependencies
Speed and Direction tests have no dependencies. Velocity tests rely on the correct operation of the Speed and Direction classes.
Success/Failure Criteria for Test Cases
Each test passes if it exactly matches a numeric or Boolean value.
Pass/Fail Criteria for the Complete Test Cycle
The cluster must pass all applied tests. As fundamental and critically important classes, they must operate as expected all the time.
Entrance and Exit Criteria
The unit test phase runs concurrently with the unit development phase. Test case construction begins while the unit's specification is being developed. Feedback from test-case development allows the developer to identify and correct inconsistencies and ambiguities in the specification.
The unit test phase is exited when the developer has implemented the required unit and it has passed all tests required by the standards defined in the test plan template.
Test Suspension Criteria and Resumption Requirements
Unit tests are suspended for one of two reasons:
- The available functionality has been adequately tested and has passed, but additional functionality remains to be developed.
- The available functionality has not passed the tests, and the developer has sufficient information to make another development pass.
Tests are resumed after the developer has constructed additional functionality or revised the existing functionality.
Test Deliverable and Status Communication Vehicles
For every unit test (of a class or a cluster of classes), the developer delivers the test class.
In this case, a class named Velocity Test is to be delivered.
Testing Tasks
Create Tables
The tables in an earlier section (Arguments for Tests) record the analysis of data values, constraints, and combinations of values.
Define DotUnit Test Class
Each test case in the tables becomes a method in the test class. An example is shown in the following figure.
Test Class
Execute DotUnit
Use the GUIRunner to execute the tests. These tests can be repeated whenever the cluster has been changed.
Evaluate Results
Differences between expected results and the execution are examined. Either the unit under test or the tests themselves may be causing the error. After test cases have been used successfully for some time, it is more likely that the unit under test is wrong, rather than the tests.
Hardware and Software Requirements
No special hardware is required for the tests of this cluster.
The DotUnit executable and the accompanying framework classes are required for building test classes.
Problem Determination and Correction Responsibilities
The developer is responsible for making corrections. Cluster users are responsible for reporting any problems to the cluster owner.
Staffing and Training Needs/Assignments
The developer of the Velocity/Direction/Speed cluster has viewed the DotUnit training module.
Test Schedules
The unit test schedule parallels the development schedule as shown in the following table.
| Test Schedule | ||
| Increment | Functionality | Schedule |
| 1 | Define the basic functionality for
Velocity. Complete functionality for Direction and Speed. |
Week of May 15 |
| 2 | Revise Speed and Direction.
Implement complete Velocity interface. |
Week of May 22 |
| 3 | Optimize the cluster. | Week of July 5 |
Risks and Contingencies
The probability of problems with this cluster is low because simple primitive classes are involved. However, the classes are critical to the success of the product line, so they must be tested thoroughly.
If these classes are not correct, there is the risk that the visible action will not be realistic and players will be frustrated.
