[
https://issues.apache.org/jira/browse/DERBY-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean T. Anderson updated DERBY-2304:
------------------------------------
Attachment: derby-2304-preview.diff
I'm working on a CallableTest.java to convert derbynet/callable.java to junit.
derby-2304-preview.diff is way incomplete, but I'm looking for feedback on the
overall structure and implementation so far. I summarized issues down below.
So far, CallableTest.java implements just 3 tests (and only runs 2 tests -- see
issue #4 down below).
The code tries to model itself after DatabaseMetaDataTest.java for reducing try
{} clutter, and after ProcedureTest.java for its basic setup, which creates all
the SQL objects up front and doesn't tear them down -- and also enables one of
the tests to run in the client framework (see issue #1). I may have gone
overboard in some cases and misunderstood stuff so please be picky!
I'm reorganizing the original test in the following ways:
- Move it from derbynet to jdbcacpi because I think it should be able to run
under both embedded and client frameworks.
- Carve it up into smaller tests.
- Create more descriptive function/procedure/method/table names like
ProcedureTest.java does; for example, instead of "CREATE FUNCTION method2"
calling "method2" I have "CREATE FUNCTION ONE_IN_ONE_OUT_FUNC" which calls
"OneInOneOutFunc" and the method that tests it is "testOneInOneOutFunc".
I ran into these issues:
1) derbynet/callable.java
Line 92 of the original test comments out the cleanup:
// stmt.execute("DROP FUNCTION method2");
I discovered that this DROP statement works fine in embedded, but raises this
exception in the client:
'DROP ROUTINE' cannot be performed on object 'ONE_IN_INE_OUT_FUNC' because
there is an open resultSet dependent on that object."
Does this error ring a bell with anyone?
ProcedureTest.java sets up everything at the start and there is no teardown, so
that's the approach I adopted with CallableTest.java. That approach enables
this test to run without error (the error did occur with my first attempt that
implemented create/drops in setup() and tearDown() methods). But I'm
uncomfortable about masking the DROP error, wonder if the current strategy will
be solid for all test scenarios.
2) Because of the client problem in #1 I initially set up baseSuite() to not
run that test in client; however, I discovered that usingEmbedded() is always
true, so I did a "Hack!" doing a string compare on embedded / client. Is this
the wrong place to exclude the run of a specific test for a given framework?
3) I created a local assertEquals(byte[] b1, byte[] b2) for the byte comparison
in testUpdateLongBinaryProc() . Is there already a way to get support for byte
comparisons? I didn't spot any. If not, is this something I should move to
BaseJDBCTestCase.java (and also completely implement)?
4) testBigDecimalInAndOutParameters() doesn't get called yet -- I need to spin
up on how to do assertEquals with BigDecimal.
For example, this assert:
assertEquals("OUT 2", new BigDecimal(33.3330), cs.getBigDecimal(2));
generates this:
OUT 2 expected:<33.33299999999999999840838> but was:<33.3330>
I'll probably start a thread on derby-dev to ask about the original objectives
of that test. I grew a little puzzled looking at it.
> Convert derbynet/callable.java to junit
> ---------------------------------------
>
> Key: DERBY-2304
> URL: https://issues.apache.org/jira/browse/DERBY-2304
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Reporter: Jean T. Anderson
> Assigned To: Jean T. Anderson
> Priority: Minor
> Attachments: derby-2304-preview.diff
>
>
> Convert the derbynet.callable.java test to the junit framework.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
