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] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
Date Mon, 25 Aug 2008 23:27:44 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625546#action_12625546
] 

Myrna van Lunteren commented on DERBY-3801:
-------------------------------------------

I see you've made no attempt at creating a ScriptTest. I think you believe a ScriptTest is
a 'tool' to convert the test to junit, and it may have started as a quick way to run certain
.sql ways in junit, but it is currently the best way to execute the language constructs that
are specific to ij.
Yes, we have in the charter to use only standard SQL, but there are some extensions that are
specific to Derby and they have to be tested also.

Language clauses as "get cursor with hold", "next", "update where current of".
So, it's important to keep a test that verifies appropriate behavior when such things are
used in ij. Thus, we *do* need a HoldCursorIJTest, but it should be extending ScriptTestCase.

However, the effort you made does not need to be thrown away - you should be able to identify
which test cases (fixtures) in what you've converted now are suitable for adding to the existing
HoldCursorTest, or maybe a HoldCursorTest2,  and which ones should stay in .sql form to be
run through a ScriptTestCase test called HoldCursorIJTest.
Where there's a difference in behavior between Embedded and DerbyNetClient it cannot be run
as a ScriptTestCase; those should be fixtures in a test without 'IJ' in the name.

Now, for the fixture you had trouble with. I also had to look for a while before I spotted
what was going on

The fixture was failing (in multiple places) but because of the teardown, we'd never see the
asserts; instead, all we'd see is complaints that the drop table t1 would not work.
It would be better to not use the setUp() and teardown() methods and instead, use a decorateSQL()
method. See other tests that use a cleanDatabaseTestSetup. 

Then, you  made a tiny mistake in comparing after the first successful update - the expected
value that gets updated is of the first row, not the second row. The expected value should
be: {{"1","12"}, {"2","2"}}. This mistake stays in all the assertFullResultSet calls.
Further, the error message resulting from the failed attempt is different for DerbyNetClient
in the converted format, it's no longer SQLState 24000.
Then, the SQLState out of the call after the ResultSet has been closed is XCL16, not 42X30.

Further, you missed checking the value after jdk4.next(). 
Do something like 
    assertEquals(1,rs.getInt(1)); 
    assertEquals(2, rs.getInt(2));

Finally two nits: 
- I think the suite() method could be structured a bit differently, it was hard to figure
out which tests were client only, embedded only, and which ones both. 
- Embedded is not always spelled with 'dd'



> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.

> --------------------------------------------------------------------------------------
>
>                 Key: DERBY-3801
>                 URL: https://issues.apache.org/jira/browse/DERBY-3801
>             Project: Derby
>          Issue Type: Test
>            Reporter: Junjie Peng
>            Assignee: Junjie Peng
>         Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, derby-3801-2.stat
>
>
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message