Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-5064

rename and revive test CheckSecurityManager

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Test
    • Urgency:
      Normal
    • Issue & fix info:
      Newcomer

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                myrna Myrna van Lunteren
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: