db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrna van Lunteren <m.v.lunte...@gmail.com>
Subject Re: proposed modification current test harness (Re: DERBY-575)
Date Thu, 06 Oct 2005 20:54:42 GMT
On 10/6/05, Daniel John Debrunner <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
> >
> > 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
 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?
  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
 Note, that currently the test harness doesn't at all handle/differentiate
os specifics - we've only jvm specific masters. Doing further os-platform
specifics is worm-farming we've managed to stay out of - so far. Most of the
os-platform-specific differences have been fairly minor (slightly different
error messages coming from the jvms) that are usually sed-ed out by test
specific sed files. DERBY-244 that I mentioned is the only issue that I've
been fearing would need os-specific canon handling.

View raw message