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.


View raw message