Derby
  1. Derby
  2. DERBY-2518

convert lang/releaseCompileLocks.sql to junit

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.4.1.3
    • Component/s: Test
    • Labels:
      None

      Description

      convert lang/releaseCompileLocks.sql to junit

      1. DERBY-2518_071707.diff
        5 kB
        Myrna van Lunteren
      2. DERBY_2518.stat
        0.2 kB
        Ramandeep Kaur
      3. DERBY_2518.diff
        10 kB
        Ramandeep Kaur

        Activity

        Hide
        Myrna van Lunteren added a comment -

        Fixed up the issues with the test pointed out by Dan with revision 557423 and 557424 to trunk.

        Show
        Myrna van Lunteren added a comment - Fixed up the issues with the test pointed out by Dan with revision 557423 and 557424 to trunk.
        Hide
        Knut Anders Hatlen added a comment -

        > hm...How do I throw the SQLException from the static initializer?

        catch (SQLException se)

        { throw new ExceptionInInitializerError(se); }
        Show
        Knut Anders Hatlen added a comment - > hm...How do I throw the SQLException from the static initializer? catch (SQLException se) { throw new ExceptionInInitializerError(se); }
        Hide
        Myrna van Lunteren added a comment -

        hm...How do I throw the SQLException from the static initializer?

        Show
        Myrna van Lunteren added a comment - hm...How do I throw the SQLException from the static initializer?
        Hide
        Myrna van Lunteren added a comment -

        Thx for the suggestions!
        I have no idea why I used endsWith(), I am sure I meant to use equals()...

        Show
        Myrna van Lunteren added a comment - Thx for the suggestions! I have no idea why I used endsWith(), I am sure I meant to use equals()...
        Hide
        Daniel John Debrunner added a comment -

        Not sure I understand these changes (e.g. in DMLInStaticInitializer.java)

        • System.out.println("Caught exception " + se);
        • se.printStackTrace(System.out);
          + if (!se.getSQLState().endsWith("38001")) { + System.out.println("Caught exception " + se); + se.printStackTrace(System.out); + }

        Printing lines to System.out in a JUnit test will not cause the test to fail if SQLState is not 38001?.

        Why not throw the exception and have the assert in the Junit class that the correct exception is thrown?

        And why endsWith() for the SQLState check?

        Show
        Daniel John Debrunner added a comment - Not sure I understand these changes (e.g. in DMLInStaticInitializer.java) System.out.println("Caught exception " + se); se.printStackTrace(System.out); + if (!se.getSQLState().endsWith("38001")) { + System.out.println("Caught exception " + se); + se.printStackTrace(System.out); + } Printing lines to System.out in a JUnit test will not cause the test to fail if SQLState is not 38001?. Why not throw the exception and have the assert in the Junit class that the correct exception is thrown? And why endsWith() for the SQLState check?
        Hide
        Myrna van Lunteren added a comment -

        attaching a patch which reinstates the use of the classes in util/StaticiInitializers.

        I modified those Initializer classes to accept the 38001 error (which apparently, based on the old masters, was fine....(??)) so that no stack trace is printed to the console from those methods.

        Show
        Myrna van Lunteren added a comment - attaching a patch which reinstates the use of the classes in util/StaticiInitializers. I modified those Initializer classes to accept the 38001 error (which apparently, based on the old masters, was fine....(??)) so that no stack trace is printed to the console from those methods.
        Hide
        Myrna van Lunteren added a comment -

        I'm fixing up the issues Dan reported...

        However, I'm wondering, what is the best way to handle this; should I remove the classes currently in package org.apache.derbyTesting.functionTests.util.StaticInitializers and include them as inner classes within the ReleaseCompileLocksTest?
        Or should I just leave them where they are and refer to them?

        Show
        Myrna van Lunteren added a comment - I'm fixing up the issues Dan reported... However, I'm wondering, what is the best way to handle this; should I remove the classes currently in package org.apache.derbyTesting.functionTests.util.StaticInitializers and include them as inner classes within the ReleaseCompileLocksTest? Or should I just leave them where they are and refer to them?
        Hide
        Daniel John Debrunner added a comment -

        Looks like the conversion of the test had a few errors.

        The routines created no longer point to a valid method, instead there external name is the result of calling that method!!
        E.g. EXTERNAL NAME '1'

        Several try catch blocks do not have a fail() assert in the path expected to fail, thus meaning the test can pass hiding real errors.

        Show
        Daniel John Debrunner added a comment - Looks like the conversion of the test had a few errors. The routines created no longer point to a valid method, instead there external name is the result of calling that method!! E.g. EXTERNAL NAME '1' Several try catch blocks do not have a fail() assert in the path expected to fail, thus meaning the test can pass hiding real errors.
        Hide
        Ramandeep Kaur added a comment -

        Attaching patch. Please review. Thanks.

        Show
        Ramandeep Kaur added a comment - Attaching patch. Please review. Thanks.

          People

          • Assignee:
            Ramandeep Kaur
            Reporter:
            Ramandeep Kaur
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development