db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: proposed modification current test harness (Re: DERBY-575)
Date Fri, 07 Oct 2005 16:58:15 GMT
Myrna van Lunteren wrote:
> On 10/6/05, *Daniel John Debrunner* <djd@debrunners.com
> <mailto:djd@debrunners.com>> wrote:
> 
>     Myrna van Lunteren wrote:
> 
>     > Hi,
>     >
>     > As a result of Dan's comments in reference to DERBY-575,
>     >
>     http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/%3c339246018.1127141188732.JavaMail.jira@ajax.apache.org%3e
>     <http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/%3c339246018.1127141188732.JavaMail.jira@ajax.apache.org%3e>
>     >
>     <http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/%3c339246018.1127141188732.JavaMail.jira@ajax.apache.org%3e
>     <http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/%3c339246018.1127141188732.JavaMail.jira@ajax.apache.org%3e>>
>     > I am proposing the following modification to the current test harness:
>     >
>     > - any read of .properties files and the like will be in original
>     encoding
>     >     effectively, this means to add 'ISO-8859-1' in a number of places
>     > where a InputStreamReader is used in the test harness classes.
>     > - the .out file will be copied into the local encoding and this
>     will be
>     > used in the diff.
>     >     I suggest giving this copied master file extension .tmpmstr -
>     which
>     > is what happens with networkserver tests.
>     >     Code may need to be added to remove the copied master if the test
>     > passes.
>     >
>     > This approach has the following benefit:
>     >     - on a non-ASCII system like zOS the tests can still be run
>     without
>     > requiring all text files to be converted first, but the generated
>     > ouptput and .diff can still be looked at and compared with expected
>     > output by a human
>     >     - the expected output is right there to compare with for a human
>     > investigating a failure, even when you're running with jars. Note that
>     > networkserver already copies the expected output.
>     >     - I am also wondering if this might get around harness bug
>     DERBY-244.
> 
> 
>     There is the problem of test development on such a platform, either for
>     new tests (and test cases) or for platform specific masters. Your scheme
>     will result in the master output being in an encoding that cannot be
>     checked into the codeline, or copied into them master directory, since
>     it is not in ISO-8859-1.
> 
>     Maybe it can be worked around by the developer switching between using
>     ISO-8859-1 and the default on that platform.
> 
>     The other risk is that a cannon will be checked into the master
>     directory that is not ISO-8859-1 encoding, since someone is runing tests
>     on such a platform.
> 
>     Dan.
> 
>  
> Thx for your input...
>  
> Maybe I'm wasn't clear on this or quite possibly I'm missing
> something...But let's take what I've been doing as an example. We start
> with the jars only. Assuming the properties files get read in ASCII (so
> the harness knows which tests to run for a suite, currently that fails),
> the harness then produces test output. The current output of the tests
> is readable on zOS. The masters however are in ASCII format, since
> they're part of a jar file. To diff those two, would mean we'd have to
> convert one or the other.
>  
> If we'd *not* make the masters files in an encoding that is readable to
> the person, then we'd need to write the output out in ASCII also, which
> is unreadable to a person. So, how could someone developing a test on
> such a system ever decide that the output is correct?

Not sure, the counter is with your solution how do they generate a
master file suitable for submitting as part of a contribution? I'm not
sure there is a good solution.

> Also, if we'd really gain a person developing on zOS, I'm assuming
> they'd also have svn on zOs. Then, wouldn't svn's eol-style native take
> care of the conversion?

No, svn eol-style only changes the end of line handling, not the content
of the file. Also this is not a problem specific to z/os, it's any
platform where the default encoding does not match the master file. More
specifically where the encoding much the same as the expected one, but
has differences.

Dan.


Mime
View raw message