The script in "Getting Started with JavaStar" tested a variety of functions in the Name Database:
These are valid tests, but, as mentioned in the chapter "Moving to the JavaStar Model," putting so many tests into a single script makes the test difficult to record and even more difficult to re-use. This lesson begins by examining TestNameDB
closely and seeing where it can be broken down into modules, represented by individual scripts.
If you look at the last test closely, you'll see that it:
Loading files, adding records, and verifying entries are likely to be operations that you do repeatedly in the test suite. By breaking these operations out into different scripts, you create more manageable files that you can then re-assemble in different configurations, based on how you want to test the application.
In addition, by breaking the tests down further to the second level of bullets, you can develop a number of test modules. You'll have more pieces to work with, but also much more flexibility in how you can combine them to form new tests.
For this lesson, you'll start re-defining the tests for Name Database, starting with a high-level definition in the Test Composer.
The JavaStar Test Composer provides you with a graphical, point-and-click way to define and assemble scripts into JavaStar Test (JST) files.
JavaStar refers to each module in a JST file as a test node. Nodes are either scripts or other JST files that execute under the conditions you define.
Nodes are connected by arrows that define their relationship to each other in the overall test graph. Connections appear as either green normal arrows or red exception arrows. These connection types--normal and exception--indicate the conditions under which the test pointed to will run.
For example, if you have a node called PopulateDB that adds a series of records to your database, and if those records are needed for the rest of the tests to continue properly, you probably want to define a normal and an exception condition.
By drawing a green arrow from PopulateDB to ChangeRecord (the first script of the rest of the test) you specify that JavaStar will execute ChangeRecord only if PopulateDB ends normally. If you then draw a red exception arrow from PopulateDB to another test node call LoadPopulatedDB--one that loads a database that already has these records included--you specify that if PopulateDB ends with an exception, the test should run LoadPopulatedDB.
You can then draw a normal, green arrow from LoadPopulatedDB to ChangeRecord, and your test has built-in recovery.
When you do not define an exception node--for example, if you defined PopulateDB to have only a normal connection to ChangeRecord--JavaStar will terminate playback when the exception is thrown. If you set up a long series of tests to run overnight, and you did not catch a recoverable condition, you've then lost valuable test time.
Defining test conditions is just one of the ways the Test Composer helps you create powerful tests. Using this tool, you can also define any node as a restart node. Restart nodes specify that the application will restart before executing the node. This is particularly helpful for recovery nodes.
The Test Composer also provides many controls for passing parameters to individual nodes and to the JST file itself. This dramatically increases the flexibility of your tests, making it easier to create one test that works in a variety of situations, all defined by parameters you specify in the JST file or at the time you run the test. This feature is explored in detail in the next chapter.
Send feedback to
JavaStar-feedback@suntest.com
Copyright © 1998
Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, CA 94303.
All rights reserved.