[
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.
