db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3088) convert to junit, or otherwise eliminate version in tests which require an update of the master in the release management process
Date Wed, 05 Dec 2007 01:21:43 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Myrna van Lunteren updated DERBY-3088:

    Attachment: DERBY-3088_ServerPropertiesTest.diff

Attaching an attempt of converting testProperties.java to ServerPropertiesTest.java.
However, this is only an initial patch, the test isn't workable yet, but I'm sort of stuck.
I hope someone can review and come up with suggestions.

The current test has the following awful problems:
- test fixtures testDefaultProperties, testTraceOn, testTraceOff and testLogConnectionsOn
attempt to use a setup that starts a networkserver process, but the setup hangs, or at least,
as best as I can tell, there's a timeout waiting for the server to start.
I tried to imitate what was done in SecureServerTest and SSLTest, but that may be part of
the problem (see also DERBY-3248, DERBY-3250, DERBY-3251)
- test fixture testWrongCommands uses NetworkServerControlMain, which is especially awful,
because it somewhere does a System.exit. Also, there is no checking of the result yet.  I
suspect this will have to do something like the ProcessStream classes of the old test harness.
- test fixture testDefaultProperties now works for me on windows, but needs to be verified
on other platforms.

One more note re the testDefaultProperties fixture: I did not use a setup for this, because
I wanted to test the starting and shutting down of servers with a different port, and the
only way I thought of to ensure the priority of the port-setting mechanisms, without hardcoding
the port(s), was to not use a setup or decorator, but to start multiple servers in sequence.
Possibly there is a smarter way to achieve this too...

> convert to junit, or otherwise eliminate version in tests which require an update of
the master in the release management process
> ---------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-3088
>                 URL: https://issues.apache.org/jira/browse/DERBY-3088
>             Project: Derby
>          Issue Type: Improvement
>          Components: Build tools, Test
>            Reporter: Myrna van Lunteren
>            Assignee: Myrna van Lunteren
>         Attachments: DERBY-3088_ServerPropertiesTest.diff
> There are a number of tests that require a master update every time the version number
is bumped.
> This is a tedious and error prone detail in the release management process.
> Currently affected masters are listed in tools/release/build.xml:
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/metadata.out
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/odbc_metadata.out
> java/testing/org/apache/derbyTesting/functionTests/master/metadata.out
> java/testing/org/apache/derbyTesting/functionTests/master/odbc_metadata.out
> java/testing/org/apache/derbyTesting/functionTests/master/NSinSameJVM.out
> java/testing/org/apache/derbyTesting/functionTests/master/checkToursDB.out
> java/testing/org/apache/derbyTesting/functionTests/master/testclientij.out
> java/testing/org/apache/derbyTesting/functionTests/master/testProperties.out
> It would streamline the release process if these tests in particular were either converted
to junit, or if the version numbers would be eliminated.
> Note: there already is a bug for metadata.java conversion: DERBY-2242

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message