Beginning with the DEV300 – OpenOffice.org 3.0 – codeline Sun QA Automation has started implementing a number of enhancements to the automated VCL Testtool scripts. The primary goal of these changes was - and is -  to gain speed while not sacrificing reliability and to reduce the maintenance overhead.

Based on the work of Thorsten Bosbach (TBO), Gregor Hartmann (GH) and Joerg Sievers (JSI) I've been working on

• Introducing the WaitSlot() command
• Replacing the filter lists by API calls
• Replacing the global Load/Save routines by UI-less functions

Today I'm talking about the new functions for saving and loading files.

Searching for ways to speed up our test scripts we quickly identified the loading/saving routines to be some of the primary time wasters - so we took a close look at the functions provided in <testtool>/global/tools/inc/t_files.inc.

What we found was that these functions have a number of drawbacks such as

• the use of localized filter names (which is something we really want to get rid off)
• the long path through the file dialogs - open the dialog, set names, paths, filters, options - which costs some five seconds per call
• the german function names that pose a challenge to each test script developer

Thorsten Bosbach pointed out that there exists another way of loading/saving the files directly by just using the FileOpen or FileSaveAs commands and pass them some additional parameters. As soon as these commands (slots) find any parameters they skip the UI part and execute directly. Here's a sample (Pseudo code, the names of the controls might be incorrect):

Classic code

FileSaveAs

Kontext "SpeichernDlg"

if ( SpeichernDlg.exists( 2 ) ) then

DateiName.setText( "/home/tester/.openoffice.org/user/work/myfile" )

DateiTyp.select( "ODT Text Document (.odt)" )

AutomatischeDateinamesErweiterung.check()

MitPasswortSpeichern.check()

Speichern.click()

sleep( 5 )

endif

New implementation

FileSaveAs( "URL", "file:////home/tester/.openoffice.org/user/work/myfile.odt", "Password", "MySecretPassword", "FilterName", "writer8", "Overwrite", TRUE )

The new implementation requires a few changes to the test script code. Most notably you cannot use the localized filternames anymore - you have to use the filters as they are required by the API (find a complete list below .../global/input/filters/api_filters.txt). Furthermore you do not have the option to automatically append a suffix which matches the filter you've selected. Here you have the option to generate a full filename by retrieving the suffix from the API (or use hGetSuffix( ... )) or to omit the suffix entirely and let the filter detection do the job for you. The latter is important when e.g. loading templates or samples where you have no idea what type of document you are dealing with. Filenames have to be passed in URL notation.

There exist a number of additional parameters to FileSaveAs(...)/FileOpen(...), such as "SynchronMode" (True/false), "AsTemplate" (True/False), "ReadOnly" (True/False), "FilterOptions" (options) and some more. However, they are not needed yet and thus are not used.

For the ease of use and compatibility considerations I've written the new functions to take the same number and order of parameters as their ancestors but still the interfaces are not guaranteed to be identical (namely the filtername, as discussed above).

You can still feed the functions with the filenames in the classic way, the conversion to platform specific file URLs is done within the new functions.

So finally you get the list of functions, their replacements, compatibility and implementation status:

These functions can be found below .../global/tools/int/t_files.inc and are automatically included when you have the LoadIncludeFiles code chunk in you .bas file.

Please note that the new functions introduce another change.

The Office loads files asynchronously. This means that we have no 100% reliable way to determine whether a document is loaded or not. Or more precisely: We know exactly when it is loaded but we have no idea when the application has really finished rendering the document. This is very important to understand: The office may not yet be ready to recieve further instructions in the instant the functions return.

There exist two functions "IsItLoaded" and "IsItSaved" that try to determine whether the office is ready or not but these are problematic and really waste a lot of time. A replacement has been provided, called hFileWait(). The new function makes use of the WaitSlot() command encapsulated in a loop which can recognize a few special conditions, such as the Macro Security warning coming up. This function appears to work reliably so far, but some real life experience is missing.

Please note that there is no timeline for the integrations/activation of the functions marked incomplete yet, this depends entirely on my workload, currently the 3.0 Beta has priority. The completed/compatible ones are already secretly called when you use the old functions. Your log contains a QAErrorLog encouraging you to swith to the new functions each time you call the old ones.

If you need more samples you may take a look at .../framework/first/inc/topten.inc which is the first test case to fully implement the new functions. And the result is significant: The test runtime decreased from 13:30 minutes to 7:30 on an average performing machine (that is a VirtualBoxed Fedora 8 on an Athlon64 X2/6000).

So once again i ask all test script coders to test these functions and give me feedback - in good or bad. I'm open for new ideas, like to hear your proposals for enhancements. Is it too complicated? Do you need more information?

tags: automated_tests