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 Thu, 06 Oct 2005 18:49:19 GMT
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.


View raw message