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] Created: (DERBY-5064) rename and revive test CheckSecurityManager
Date Tue, 22 Feb 2011 13:13:39 GMT
rename and revive test CheckSecurityManager

                 Key: DERBY-5064
                 URL: https://issues.apache.org/jira/browse/DERBY-5064
             Project: Derby
          Issue Type: Improvement
          Components: Test
            Reporter: Myrna van Lunteren
            Priority: Minor

The test derbynet/CheckSecurityManager was created as a result of an attempt to convert checkSecMgr.java
to junit (revision 532853 (http://svn.apache.org/viewvc?view=revision&revision=532853),
but was subsequently disabled with by removing it from derbynet._Suite with revision 532992
(http://svn.apache.org/viewvc?view=revision&revision=532992) with the following comment:

        // Disabled due to "java.sql.SQLSyntaxErrorException: The class
        // 'org.apache.derbyTesting.functionTests.tests.derbynet.checkSecMgr'
        //  does not exist or is inaccessible. This can happen if the class is not public."
        //  in the nightly tests with JDK 1.6 and jar files.

That error is easily seen when running the test manually, but it's just as easily fixed by
correcting the name in the create procedure call in CheckSecurityManager.

However, there are more things wrong with this test before reinstating makes sense;
- the name does not match our current de facto standard of ending with Test. If we're fixing
up this test, we might as well rename it to CheckSecurityManagerTest (and remember to change
the name in the header and in the stored procedure also)
- the (almost) working check passes whether there's an error 38000 or not; will only fail
if we see an error *other* than 38000.
There should at least be fail check after the cstmt.executeUpdate() call.
- the test could be changed to use some of the BaseJDBCTestCase methods
more interesting:
- the disabled test case could be made to work - perhaps as indicated the database should
be created using a relative path/and or another constructor. That test case also does a Class.forName
to the jcc driver, which needs to be replaced (perhaps that's being done alread in re DERBY-4785).
It suggests a hard-coded windows path, which also wouldn't work well.
I think it's perhaps this part of the test case that once upon a time resulted in the error
of DERBY-2448.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message