[jira] Issue Comment Edited: (DERBY-3088) convert to junit, or otherwise eliminate version in tests which require an update of the master in the release management process

["Myrna van Lunteren (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565517#action_12565517 ] 

myrna edited comment on DERBY-3088 at 2/4/08 12:50 PM:
--------------------------------------------------------------------

I've been looking at the last remaining test master/canon - testclientij.out - that shows the version number.
It looks like this test was explicitly intended as a .sql test to test DerbyNetClient connection strings, so converting to a .java junit test does not seem appropriate.

The difference between other tests executing .sql files (e.g. NistScripts, LangScripts, ToolScripts) is that this one emulates the old harness' RunTest mechanism of using ij.main("-fr", "filename") (by extending util.IjTestCase), whereas the other tests use ij.runScript(..).

-fr is possibly intended to be a undocumented feature, at least, I could find no documentation, even the ij javadoc is very quiet about it, and if you use it incorrectly, (e.g. : java org.apache.derby.tools.ij testclientij.sql) you get an NPE rather than an appropriate message.
I gather it's supposed to list the file in it's full resource path - e.g.: java org.apache.derby.tools.ij /testclientij.sql (if . is in your classpath and the file sits in the current dir).

Apparently, and per the code, running main vs runScript results in some slight differences:
- no version number printed
- first connection is already started
- no messages indicating number of rows selected
These differences do not seem relevant to this particular test.

I think the util.IjTestCase mechanism may possibly be of use in testing ij in the future, but at present, in NetIjTest, it appears to be just another way of doing the same thing as e.g. NistScripts, a way that has the unfortunate effect of printing the version number.

We could consider adding the script to the tools directory/_Suite...But I think it is more appropriate in its current spot. Thus, I intend to rewrite NetIjTest to use the same mechanism as NistScripts. When this is done, I intend to get rid of the master-editing target in tools/release/build.xml.
I'll leave IjTestCase in place for future use. If used, it would need a different compareCanon method in CanonTestCase, one that ignores lines with specified strings (or maybe specifically checks on the version number without it being in the canon).


      was (Author: myrna):
    I've been looking at the last remaining test master/canon - testclientij.out - that shows the version number.
It looks like this test was explicitly intended as a .sql test to test DerbyNetClient connection strings, so converting to a .java junit test does not seem appropriate.

The difference between other tests executing .sql files (e.g. NistScripts, LangScripts, ToolScripts) is that this one emulates the old harness' RunTest mechanism of using ij.main("-fr", "filename") (by extending util.IjTestCase), whereas the other tests use ij.runScript(..).

-fr is possibly intended to be a undocumented feature, at least, I could find no documentation, even the ij javadoc is very quiet about it, and if you use it incorrectly, (e.g. : java org.apache.derby.tools.ij testclientij.sql) you get an NPE rather than an appropriate message.
I gather it's supposed to list the file in it's full resource path - e.g.: java org.apache.derby.tools.ij /testclientij.sql (if . is in your classpath and the file sits in the current dir).

Apparently, and per the code, running main vs runScript results in some slight differences:
- no version number printed
- first connection is already started
- no messages indicating number of rows selected
These differences do not seem relevant to this particular test.

I think the util.IjTestCase mechanism may possibly be of use in testing ij in the future, but at present, in the NetIjTest, it appears to be just another way of doing the same thing as e.g. NistScripts, a way that has the unfortunate effect of printing the version number.

We could consider adding the script to the tools directory/_Suite...But I think it is more appropriate in it's current spot. Thus, I intend to rewrite NetIjTest to use the same mechanism as NistScripts. When this is done, I intend to get rid of the master-editing target in tools/release/build.xml.
I'll leave IjTestCase in place for future use. If used, I would need a different compareCanon method in CanonTestCase, one that ignores lines with specified strings (or maybe specifically checks on the version number without it being in the canon).

  
> 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, DERBY-3088_ServerPropertiesTest2.diff, DERBY-3088_ServerPropertiesTest_3.diff, DERBY-3088_ServerPropertiesTest_3.stat
>
>
> 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.