Moving to the JavaStar Model: Deficiencies of the Previous Approach
After recording TestNameDB
, you're probably all too familiar with how tedious it can be to record a long script from start to finish. This may be especially true if you encountered a problem and had to do the script over. It's a painstaking process that yields an awkward test.
Some of the deficiencies of TestNameDB
are:
- There is no abstraction from the interface of the application under test. If one or more components of the application under test change, you have to update every reference to the modified components.
- The script combines several tests into a single script (loading a database, adding a new record, and verifying the record using the search window). This:
- Makes the script difficult to record without making an error.
- Limits re-use potential, because you can only re-use this script if you want to test these three functions in this same order. Otherwise, the script isn't useful beyond one test run per application release.
- Outputs results that are long and hard to navigate. JavaStar provides a feature that jumps ahead to each failure, but if you're looking for something other than failure, wading through these results is tough work.
- The script uses hard-coded data, not allowing you to test the same features with different data--unless you want to maintain copies of the script that use different data.
Fortunately, each of these deficiencies can be overcome with a change of approach.
Send feedback to
JavaStar-feedback@suntest.com
Copyright © 1998
Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, CA 94303.
All rights reserved.