Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 61472 invoked from network); 7 Feb 2007 18:15:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Feb 2007 18:15:27 -0000 Received: (qmail 60028 invoked by uid 500); 7 Feb 2007 18:15:33 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 60006 invoked by uid 500); 7 Feb 2007 18:15:33 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 59997 invoked by uid 99); 7 Feb 2007 18:15:33 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Feb 2007 10:15:33 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Feb 2007 10:15:25 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 845EA7142B5 for ; Wed, 7 Feb 2007 10:15:05 -0800 (PST) Message-ID: <385857.1170872105505.JavaMail.jira@brutus> Date: Wed, 7 Feb 2007 10:15:05 -0800 (PST) From: "Jean T. Anderson (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-2304) Convert derbynet/callable.java to junit In-Reply-To: <28937294.1170871390412.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ 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.