db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean T. Anderson (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2304) Convert derbynet/callable.java to junit
Date Wed, 07 Feb 2007 18:15:05 GMT

     [ 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

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.

View raw message