GullFOSS
OpenOffice.org Engineering at Sun
 
 
 
 
More Flickr photos tagged with openoffice

Today's Page Hits: 802

Locations of visitors to this page
« OpenOffice.org 3.0... | Main | Development at a... »
Friday, 29 Feb 2008
QA Automation – Filter names For All Locales And Brands
Joerg Skottke

Since the time when StarOffice went Open Source the QA and especially the QA Automation faces a number of new challenges. The ones with the highest impact are localization and branding.

In the past it was quite feasible to maintain a list of filter names – there were only a few brands and locales. But in the last years this has become increasingly cumbersome and a serious blocker for many volunteer-testers around the world. Each time a new translation for OpenOffice.org emerges somebody has to create and maintain a list of filters in order to use the QA Testtool for a specific language.

We (QA Automation at Sun) have maintained these lists because we wanted to have the means to discover unexpected changes in filter names which might be introduced by faulty translations or a broken configuration and a few other rare things. However, this simply does not work anymore.

So we have decided to take a new approach which is simply to retrieve the filter names from the OpenOffice.org configuration via API. This means that in the future it does not matter anymore which language you are testing, you should always get your localized filter name without the need to maintain any filter lists within the global module.

The changes are going to be effective as of tomorrow morning for CVS HEAD – which means OOo 3.0.


Here you have a few technical details:

The changes to the Testtool Scripts are significant. The affected files are

which have been rewritten in large parts. Additionally we remove most of the files below global/input/filters as they are not needed anymore.

To maintain compatibility to the test scripts I've introduced two matching tables named „build_to_xxx.txt“ within the global/input/filters directory which allow to call functions like „hGetFilter()“ with unchanged parameters. However, they are bound to vanish at some time in the future.

Alongside with the new implementations i've taken the liberty to update the files to comply to the coding guidelines and a few minor speed optimizations have been done in places where this could be done with little to no risk.


Beware!

The new method relies on a number of implementation details – the function that retrieves the suffixes from the API always returns the first hit. In case of HTML you might end up with a suffix .HTML or .HTM. The same happens for CSV suffixes which might be .TXT, .CSV, .SYLK, even .XLS. Currently you get the suffix that is listed first within the configuration file.

Something very similar can happen when you try to use e.g. the „StarWriter 5.0“ filter. If – for any reason – the „StarWriter 5.0 Template“ comes first in the File Save dialogs filter list, you're toast.

During countless test runs these issues never emerged, but who knows? So if you encounter any problems with the new implementation: Contact me, ideally by submitting a bug

From now on we do not verify the validity of the filters with each test anymore. A replacement has been in place for a long time though, which is the framework/filedlg/filedlg_filternames.bas. If you want to check the filters for your language in the future, please use this test.


The larger context:

The long term goals of these modifications are to reduce the maintenance effort within the „global“ module and to gain more speed and thereby enabling more people to just use the Testtool out of the box.

The next steps could be to clean up some global modules, to remove some if not all unused functions – and at a later point to implement a new function for all hSpeichern...() functions which does not use the File Save dialog anymore but instead does an API call.


tags:

Posted by Joerg Skottke on 29 Feb 2008  |  PermaLink |  Bookmark to Delicious To Delicious |  Digg this Digg this

Comments

Post a Comment:
Comments are closed for this entry.
« OpenOffice.org 3.0... | Main | Development at a... » GullFOSS