About JavaStar: Composing Tests from Scripts


In the JavaStar model, you create small, re-usable scripts that address specific functionality and join these together to compose complex tests.

While it might, at times, seem easier to record a complete test in one script, start to finish, this approach limits your ability to expand and maintain the script. The script can't be reused for other purposes, and the length and complexity makes it difficult to keep up to date.

With the modular script approach, the scripts you write are focused and compact. For example, you might write one script that tests a specific dialog window and nothing else. You can use this script in any test where you bring up that same dialog window. If the window changes, you only have to change this one script. And if you decide you want to improve the testing within the script, your changes immediately update all tests that call this script.

Of course, this concept isn't new; it's the foundation of object-oriented programming. What's different is that JavaStar is built around this model, and includes features that make the implementation as efficient as possible.

Composing Tests in JavaStar

In JavaStar, you combine scripts into tests using the Compose Test feature. In Compose view, every script is a node in a test tree that you design. The tree is displayed graphically, making it easy to move nodes around and define their attributes. You define the relationships between nodes--whether their dependency is based on a normal condition or an exception--to define the test flow based on results. This provides you with a way to recover from (but still capture) failures that might otherwise halt automated testing and waste time.

You can also define whether a node is a restart node (restarting the test application or applet) and you can pass parameters to any node with a script that accepts them.

An example of a composed test

As an example, Figure 1-1 shows a simple test composed using five scripts. These tests execute against a small name database applet that requires data to reveal some of the GUI components. Each script in the test represent an discrete tasks--one that might well be needed by other tests for this applet.

Scripts joined together to form a single test

In this composition:

  1. The LoadCleanDatabase node (the root node) starts the test applet. This happens without any direction from the user.

  2. LoadCleanDatabase prepares the test environment by loading an empty database in to the applet, then checks to see if the database loads correctly.

  3. If the database loaded correctly, the script ends normally and continues on to PopulateDatabase.

  4. If, however, LoadCleanDatabase throws an exception, the LoadPopulatedDatabase script executes instead, restarting the application and loading a populated database, thus recovering the situation.

  5. If PopulateDatabase can't finish normally, it also calls LoadPopulatedDatabase as a recovery mechanism.

  6. When PopulateDatabase or LoadPopulatedDatabase complete normally, the VerifyNames script executes next.

In this small test sample, you can see how the reusable features of scripts and the controls available when composing tests can come in handy. With carefully planned tests, you can write test suites that execute for longer periods of time and provide you with more information. You can build new tests out of similar components. And, if you enhance a script (or write your own from scratch) using Java, you can pass parameters to that script as part of your test. This moves your testing beyond simple record-and-playback scenarios.




Send feedback to JavaStar-feedback@suntest.com
Copyright © 1998 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, CA 94303. All rights reserved.