Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.4.1.3
    • Component/s: Test
    • Labels:
      None
    • Environment:
      windows XP Professional SP2,
    • Urgency:
      Normal
    • Issue & fix info:
      Patch Available

      Description

      It is a task of "Converting old tests to JUnit ". It request coverting "derdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/big.sql" into a junit. Also, it is a task of 2008 GSoc.

        Activity

        Hide
        Junjie Peng added a comment -

        Good message! I will close this issue some later.

        Show
        Junjie Peng added a comment - Good message! I will close this issue some later.
        Hide
        Kathey Marsden added a comment -

        Thanks Junjie, I committed the patch with revision 673136. I removed big.sql big_derby.properties and the master (big.out) files. Even though big_derby.properties had lock timeouts set to a lower timeout I don't see that that was necessary for the test because it doesn't have any lock timeouts as far as I can tell. I think you can go ahead and resolve/close this issue once the nightly tests run.

        Show
        Kathey Marsden added a comment - Thanks Junjie, I committed the patch with revision 673136. I removed big.sql big_derby.properties and the master (big.out) files. Even though big_derby.properties had lock timeouts set to a lower timeout I don't see that that was necessary for the test because it doesn't have any lock timeouts as far as I can tell. I think you can go ahead and resolve/close this issue once the nightly tests run.
        Hide
        Junjie Peng added a comment -

        Thanks for Bryan and Kathey! I have provided a new patch with changes below:
        In this path, I have changed testVarchar() and testLongVarchar() to just test the max length of varchars to be OK.
        Rename testJCCQueryBlock () to testDefaultQueryBlock(), and change the comments to indicate client instead of JCC.
        Remove big.sql from the old harness.
        Add my new test to lang._Suite.
        Please check it!

        Show
        Junjie Peng added a comment - Thanks for Bryan and Kathey! I have provided a new patch with changes below: In this path, I have changed testVarchar() and testLongVarchar() to just test the max length of varchars to be OK. Rename testJCCQueryBlock () to testDefaultQueryBlock(), and change the comments to indicate client instead of JCC. Remove big.sql from the old harness. Add my new test to lang._Suite. Please check it!
        Hide
        Kathey Marsden added a comment -

        >For testVarchar(), When creating the table, a SQLException is thrown with the prompt >that 32767 is a invalid length.
        I think you should create the table with the maximum size allowed and only insert rows that will fit.

        >For testLongVarchar(), When inserting a big row with the length of 33000, a >SQLException is thrown with the prompt that 33000 is a invalid length.

        Again only insert colums that will fit up to the max.

        >I have another question: I have 10 test***() methods and 1 suite() method in the class >of BigDataTest. When I run this test, I have seen 20 test cases run. What's the problem?
        Yes you are testing with both embedded and network client so this is expected.

        I will take a closer look at the patch later today. A couple things I noticed glancing at it briefly is that you should remove big.sql from the old harness and add your new test to lang._Suite.

        Also we should rename testJCCQueryBlock to testDefaultQueryBlock and change the comments to indicate client instead of JCC.

        Show
        Kathey Marsden added a comment - >For testVarchar(), When creating the table, a SQLException is thrown with the prompt >that 32767 is a invalid length. I think you should create the table with the maximum size allowed and only insert rows that will fit. >For testLongVarchar(), When inserting a big row with the length of 33000, a >SQLException is thrown with the prompt that 33000 is a invalid length. Again only insert colums that will fit up to the max. >I have another question: I have 10 test***() methods and 1 suite() method in the class >of BigDataTest. When I run this test, I have seen 20 test cases run. What's the problem? Yes you are testing with both embedded and network client so this is expected. I will take a closer look at the patch later today. A couple things I noticed glancing at it briefly is that you should remove big.sql from the old harness and add your new test to lang._Suite. Also we should rename testJCCQueryBlock to testDefaultQueryBlock and change the comments to indicate client instead of JCC.
        Hide
        Bryan Pendleton added a comment -

        > I have 10 test***() methods and 1 suite() method in the class of BigDataTest. When I run this test, I have seen 20 test cases run

        How are you running the test? Is it possible that you are running
        the test in multiple configurations? For example, perhaps you
        are running the 10 test methods in embedded mode, and then
        running the same 10 test methods again, in client-server mode?

        Show
        Bryan Pendleton added a comment - > I have 10 test***() methods and 1 suite() method in the class of BigDataTest. When I run this test, I have seen 20 test cases run How are you running the test? Is it possible that you are running the test in multiple configurations? For example, perhaps you are running the 10 test methods in embedded mode, and then running the same 10 test methods again, in client-server mode?
        Hide
        Junjie Peng added a comment -

        New patch for big.sql.
        I have accepted Myrna's advices, and do some improvement.
        In this patch, I also add some test cases for the parts in "big.sql" which is commented.
        i.e. Mix clob and varchar in the table, the test case will be supported without DRDAProtocolException exception is thrown.
        I also add testStringTable(), testLongVarchar() and testVarchar(). testStringTable() has been proved not supported yet, so I commented it again. For testVarchar(), When creating the table, a SQLException is thrown with the prompt that 32767 is a invalid length. For testLongVarchar(), When inserting a big row with the length of 33000, a SQLException is thrown with the prompt that 33000 is a invalid length.
        In this situation, whether should I add testLongVarchar() and testVarchar() as new test cases.
        I have another question: I have 10 test***() methods and 1 suite() method in the class of BigDataTest. When I run this test, I have seen 20 test cases run. What's the problem?

        Show
        Junjie Peng added a comment - New patch for big.sql. I have accepted Myrna's advices, and do some improvement. In this patch, I also add some test cases for the parts in "big.sql" which is commented. i.e. Mix clob and varchar in the table, the test case will be supported without DRDAProtocolException exception is thrown. I also add testStringTable(), testLongVarchar() and testVarchar(). testStringTable() has been proved not supported yet, so I commented it again. For testVarchar(), When creating the table, a SQLException is thrown with the prompt that 32767 is a invalid length. For testLongVarchar(), When inserting a big row with the length of 33000, a SQLException is thrown with the prompt that 33000 is a invalid length. In this situation, whether should I add testLongVarchar() and testVarchar() as new test cases. I have another question: I have 10 test***() methods and 1 suite() method in the class of BigDataTest. When I run this test, I have seen 20 test cases run. What's the problem?
        Hide
        Junjie Peng added a comment -

        Myrna:
        Thank you for the verbose instructions from you and Kathey! I accept your comments and will do the improvement. It seems most of my problem comes from not so good understanding of BaseJDBCTestCase, and I will reuse more reusable things.

        ---My IDE is Eclipse on Windows XP, I use subclipse to check and create the patch, the result starts with
        "Index: D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java
        ===================================================================
        — D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0)
        +++ D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0)"

        I do know why it doesn't include a revision number. And "D:/myproject/java/eclipse/java" was deleted by hand. I have done another testing — if I change a class file which has been submitted, the patch will include some Non-ASCII code. Maybe I should try SVN.

        ----Besides, I have another question:
        Where to put unit test codes for the unit test itself? When I do this converting, I have a trouble in doing unit testing for my new test case. So far, I just put the testing codes in the same class file, then delete all of them before submit. It is not so smart. How should we deal with this problem?
        Thank you!

        Regards
        Junjie

        Show
        Junjie Peng added a comment - Myrna: Thank you for the verbose instructions from you and Kathey! I accept your comments and will do the improvement. It seems most of my problem comes from not so good understanding of BaseJDBCTestCase, and I will reuse more reusable things. ---My IDE is Eclipse on Windows XP, I use subclipse to check and create the patch, the result starts with "Index: D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java =================================================================== — D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0) +++ D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0)" I do know why it doesn't include a revision number. And "D:/myproject/java/eclipse/java" was deleted by hand. I have done another testing — if I change a class file which has been submitted, the patch will include some Non-ASCII code. Maybe I should try SVN. ----Besides, I have another question: Where to put unit test codes for the unit test itself? When I do this converting, I have a trouble in doing unit testing for my new test case. So far, I just put the testing codes in the same class file, then delete all of them before submit. It is not so smart. How should we deal with this problem? Thank you! Regards Junjie
        Hide
        Myrna van Lunteren added a comment -

        Thanks for this great first effort!

        Kathey and I put our heads together and noticed the following:

        • what tool did you use to create the patch? Normally, patches are created using svn diff from the top of the trunk. That way, the diff would have something like:
          =========================================================
            • java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0)
              +++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0)

        In your patch, we miss the revisions, and there's an extra level ('derdy')

        • at Derby, we have to convention to not use @author tags. (ownership & history is documented in JIRA and svn)
        • BIG_TABLE_NAME should be static
        • There should be no need for private Connection conn. The fixtures can just call 'getConnection' (picking up from BaseJDBCTestCase) to connect to the default db
        • similarly, you don't need to use Statement stmt = conn.createStatement(...), you can just use createStatement(int resultSetType,int resultSetConcurrency) from BaseJDBCTestCase.
        • it would be good to have a suite() method using defaultSuite. That way the test would run automatically with both embedded and network server/client, using cleanDatabaseSetup to remove all tables from the db between fixtures.
        • instead of validTabe() and validRows() it looks as if you should be able to use one of the JDBC.assertFullResultSet() methods
        • At the end of big.sql there are various tests commented out because at one point it wasn't supported. Some of that functionality is (again?) supported; you should be able to insert characters into tables with datatype char, varchar, long varchar. (The max lengths are different per char - should be in the manual). You should see if those test cases can be revived.
        • the fixture 'testMixture' is based on a section that in big.sql has half of it commented out, mentioning some problem with getting a DRDAProtocolException. This section should make it into the test - if it does still return a protocolException it can be commented out with reference to a JIRA (I looked, but it doesn't appear one was logged, so that would need to get done too, if reproducible).
        • nit: we usually have the code inside a method indented 8 spaces.

        In general, there's a utility that we can use to convert .sql type tests to junit type tests - org.apache.derbyTesting.functionTests.util.SQLToJUnit - when you use it, a lot of the conversion should get done for you.

        Show
        Myrna van Lunteren added a comment - Thanks for this great first effort! Kathey and I put our heads together and noticed the following: what tool did you use to create the patch? Normally, patches are created using svn diff from the top of the trunk. That way, the diff would have something like: ========================================================= java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0) +++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0) In your patch, we miss the revisions, and there's an extra level ('derdy') at Derby, we have to convention to not use @author tags. (ownership & history is documented in JIRA and svn) BIG_TABLE_NAME should be static There should be no need for private Connection conn. The fixtures can just call 'getConnection' (picking up from BaseJDBCTestCase) to connect to the default db similarly, you don't need to use Statement stmt = conn.createStatement(...), you can just use createStatement(int resultSetType,int resultSetConcurrency) from BaseJDBCTestCase. it would be good to have a suite() method using defaultSuite. That way the test would run automatically with both embedded and network server/client, using cleanDatabaseSetup to remove all tables from the db between fixtures. instead of validTabe() and validRows() it looks as if you should be able to use one of the JDBC.assertFullResultSet() methods At the end of big.sql there are various tests commented out because at one point it wasn't supported. Some of that functionality is (again?) supported; you should be able to insert characters into tables with datatype char, varchar, long varchar. (The max lengths are different per char - should be in the manual). You should see if those test cases can be revived. the fixture 'testMixture' is based on a section that in big.sql has half of it commented out, mentioning some problem with getting a DRDAProtocolException. This section should make it into the test - if it does still return a protocolException it can be commented out with reference to a JIRA (I looked, but it doesn't appear one was logged, so that would need to get done too, if reproducible). nit: we usually have the code inside a method indented 8 spaces. In general, there's a utility that we can use to convert .sql type tests to junit type tests - org.apache.derbyTesting.functionTests.util.SQLToJUnit - when you use it, a lot of the conversion should get done for you.
        Hide
        Junjie Peng added a comment -

        I added a TestCase named "BigDataTest" for "big.sql", please check it. It is one of my tasks for 2008 GSOC. Hope for instructions, especially from my sincere mentor Myrna!

        Show
        Junjie Peng added a comment - I added a TestCase named "BigDataTest" for "big.sql", please check it. It is one of my tasks for 2008 GSOC. Hope for instructions, especially from my sincere mentor Myrna!

          People

          • Assignee:
            Junjie Peng
            Reporter:
            Junjie Peng
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 168h
              168h
              Remaining:
              Remaining Estimate - 168h
              168h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development