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-5064) rename and revive test CheckSecurityManager
Date Tue, 22 Feb 2011 13:19:38 GMT

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

Myrna van Lunteren updated DERBY-5064:

    Labels: derby_triage10_8  (was: )

> 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
>              Labels: derby_triage10_8
> 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.
>         //suite.addTest(CheckSecurityManager.suite());
> 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;
> simple:
> - 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