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
 Assigned to: 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

Reply via email to