[
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
