You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <ji...@apache.org> on 2007/12/05 02:21:43 UTC

[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

     [ 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.