db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-658) test harness improvements required for running on non-ASCII systems
Date Fri, 07 Apr 2006 06:41:32 GMT
    [ http://issues.apache.org/jira/browse/DERBY-658?page=comments#action_12373581 ] 

Myrna van Lunteren commented on DERBY-658:
------------------------------------------

While I am getting closer to finish steps 2-5, I have some questions re step 6.

Currently, I think the easiest way to implement it is to read the .out file generated in local
encoding (which is how it's always been) back in and write it out in fixed encoding.
I was thinking of adding a property, say, generateUTF8Out, into RunTest, which would create
an additional file, <testname>.utf8out. Basically, the harness would do what native2ascii
does.

It would mean that a developer would have to run an individual test with the generateUTF8Out
property on the command line (not in properties files), then copy the <testname>.utf8out
to the location for the <testname>.out in the source tree, instead of the .out, as we'd
do currently. All this would only be necessary if you're working in a non-UTF-8 compatible
encoding, I think.

Is this an OK approach?

Myrna

> test harness improvements required for running on non-ASCII systems
> -------------------------------------------------------------------
>
>          Key: DERBY-658
>          URL: http://issues.apache.org/jira/browse/DERBY-658
>      Project: Derby
>         Type: Bug

>   Components: Test
>     Versions: 10.1.1.0
>  Environment: all but especially testing should be done on zOS
>     Reporter: Myrna van Lunteren
>     Assignee: Myrna van Lunteren
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> The current functionTests test harness needs adjustment for running on non-ASCII systems
like zOS.
> Currently, when using derbyTesting.jar built for instance on a windows or linux system
on zOS the tests do not run, because the properties and runall files cannot be understood.

> Until now, testers on zOS had to unjar derbyTesting.jar, then run native2ascii -Cp 1047
-reverse on all appropriate files (.sql, .txt, .out, .properties, .runall, .asc, .exclude,
etc). 
> This is a labor intensive and error prone process. Furthermore, it causes test failures
such as reported with DERBY-575, because tests may assume a certain file to be a specific
length, which no longer holds true after the native2ascii conversion.
> The test harness should get modified to always read the files in the same encoding.
> Note however, that the comparison of actual .out and the master should still result in
files readable on the local system, to enable a human to evaluate failures and results. At
the same time, this raises the concern that someone might check-in an update to the master
with an incorrect encoding.
> To resolve the main issue, I propose the following:
> -  Set the default encoding in the harness.
> - for each test 
> 1)  determine if the test encoding is set. We can probably use ij.ui.codeset - otherwise
a new property is needed.
>      Note that this means that .properties, .runall and .exclude  files are always read
in fixed/default encoding.
> 2) read the master/sql files in in the default/fixed encoding unless the encoding property
is set for a test
> 3) Write the output out in the local encoding (the way is done currently) unless the
encoding property is set (if set, write out in that encoding)
> 4) Change the code that creates tmpmstr to always apply instead of only for networkserver.
tmpmstr files will be created in the local encoding.
> 5) Have FileCompare  read tmpmstr in in the local encoding for the comparison.
> 6) either document that test development/adjustment need to be at least be verified on
an ascii system, or add another property that causes a copy of the actual output to be created
in the default/fixed encoding.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message