Using the JavaStar API: Opening Files


If you have been working on the other lessons in this tutorial, you've spent a lot of time on OpenFile. This lesson has a different application, but still has a file to open, so you're going to spend more time; however, you can build on what you've learned and use methods in the API to make your file handling even more rigorous.

You are going to work with these methods in this part of the lesson:

Examining the Recorded Open

Start by recording a script that opens a file.

  1. From the main JavaStar window, click Create a Test Script, and click Start to run the application.

  2. Click Record. Name the script openAction.

  3. From the application, pull down the File menu, and select Open.

  4. Open the file:

  5. Verify that the label on the left reads "newfilew."

  6. Stop the recording, and Quit the "Record/Playback" window.

This is pretty much the same as you did before. You edited that script to replace the hard-coded file name with an argument. That is better, but you can do better still. Here are some of the problems that remain with a file-opening script, even if you make the file name a variable:

Next, you will examine each of these in detail and see solutions available to lessen the problems with scripts that address files.

Separating Test Set-up Verification

Two things are being tested in the openAction script:

For better reuse, use two scripts.

The first, VerifyTestFile:

The second, openAction:

If VerifyTestFile fails, it means that test file wasn't set up properly. If openAction fails, the application has a problem opening the file. This makes error assignment and debugging much clearer than leaving it all in one script. VerifyTestFile becomes very reusable for any application using that file.

Removing Platform and Path Dependence

Examine your openAction script by viewing it in the script editor.

  1. Click Edit Test Script. Browse to find:

  2. Scroll to the play() method. Notice the call to the file dialog simulation:

  3. Click Close.

In a previous exercise, "Adding Parameters for Flexibility", you replaced the file name "newfilew" with an argument that is passed to the test at run time. While this improves the script and makes it more flexible, please note that the directory, the first argument to the JSComponent.relativefile() method, remains hard-coded. This string is dependent on two things, each of which makes this script fragile and less portable:

To correct this, make the directory, as well as the file, an argument. It would be preferable to specify the path as absolute, rather than relative. You'll do this in a few moments.

Removing False Exceptions

Should the openAction script fail to open a test file that is known to exist, it is most likely a problem in the application code. The proper behavior is to note that error against the application.

However, as the code uses a variable label to show that the file has been open, the verify on this label will fail with a GUINotFoundException.

The ideal correction to this is to change the application code itself to use a setName() for this component. Then, if JavaStar is instructed to use component names, the text of the label will not become the actual name of the component.

However, the TCTester application does not use setName(). We can compensate by catching the GUINotFoundException within the script, and posting an error to the log by using JS.check().

Now let's actually create the VerifyTestFile and openAction scripts.

Building VerifyTestFile

Create a template script and edit it to code the required instructions.

  1. Click Create a Test Script. Start the Application.

  2. Record. Name the script VerifyTestFile.

  3. Immediately click Stop to stop recording.

  4. Click Quit to close the "Record/Playback" window.

  5. Edit the script. Browse to open:

  6. Import the IO classes you will need.
    Add:
    to the import statements.

  7. Assign the two arguments to variables with better names. Validate to ensure the arguments are not empty or null. Put this code at the beginning of the play() method.

JS.note() is the API method that allows you to post a string to the test result file. Here you use it to add a better explanation for what caused the exception.

  1. Enter the code to ensure the file exists. The code below has the required calls to the API.

  2. Gather other information about the file for use in later scripts.
    It is better to get that data now, rather than try to access the file while the application has it open, as you may accidentally cause a problem trying to open it twice. Here is the code to gather the information through the file API.

  3. Place the file information in a property file that can be accessed by other scripts.
    JavaStar maintains an internal property file that all scripts can access within any one execution of a test. To place items in this file, assign them a key name, and use JS.setProperty(String keyname, String value) to update the file. Here is the code that sets the values in the property file and notes to the log what those values are.

  4. Save and compile the script. Don't close the editor yet.

Edit openAction

  1. From the Script Editor, browse to find the script:

  2. Locate the play() method. All your updates will go within the brackets of this method.
    }

  3. Get the file directory and file name properties, and assign them to variables. Place this code at the beginning of the play() method.

  4. Locate the call to relativefile() and correct it.
    There is a parallel method, choosefile() that uses an absolute path. Change to this method, and use the values from the properties for the input parameters.

  5. Locate the verification of the label, and change it to use the variable filename.

  6. Enclose that verification in a try/catch loop that catches an exception and posts an error to the log instead.

  7. Save and compile the script. Close the Script Editor.

Now that you have built the scripts, you can build a test that contains them.

Build the JST

By creating a test that contains the pair, you have the effect of a single script similar to the OpenFile you created for the Name application. This test can be used within other tests, and the properties it sets can be addressed by the other scripts.

If you are not familiar with using the test composer, please see "Composing Tests" in the JavaStar User's Guide.

  1. Click Compose Test. Enter OpenTCFile as the jst name.

  2. Add the scripts VerifyTestFile and openAction.

  3. Map the first two jst arguments, 0 and 1, to the first two arguments of VerifyTestFile. Use the Edit button.

  4. Create a normal flow between VerifyTestFile and openAction.

  5. Save the test.

  6. Close the Test Composer.

Now you are ready to test your test.

Run the Test

  1. Run Test. Browse to find:

  2. Enter the arguments /tutorial/API/TCTester for the directory, and fileOfThree for the file name. Adjust the directory path as needed to be correct for your platform.

  3. Start the test. It should run to completion.
    Examine the test results to see the notes you have made.

  4. Try the test several other times using different arguments, such as the absolute path for the directory, an invalid directory, an invalid file name, etc.

At this point, you have learned to build a robust file-handling test.




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