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.