Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 76028 invoked from network); 19 Jun 2008 15:11:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Jun 2008 15:11:36 -0000 Received: (qmail 7615 invoked by uid 500); 19 Jun 2008 15:11:37 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 7595 invoked by uid 500); 19 Jun 2008 15:11:37 -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 7584 invoked by uid 99); 19 Jun 2008 15:11:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Jun 2008 08:11:37 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,NORMAL_HTTP_TO_IP,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of pjj.ccce@gmail.com designates 209.85.198.225 as permitted sender) Received: from [209.85.198.225] (HELO rv-out-0506.google.com) (209.85.198.225) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Jun 2008 15:10:47 +0000 Received: by rv-out-0506.google.com with SMTP id f6so6033954rvb.55 for ; Thu, 19 Jun 2008 08:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=E6gzmWbGDGz+bJ0nOq7+RYH3k4MojTXWk+R7aY7lgOI=; b=wHjxRlF7sRpy2YvDfRm19IcpUcNCT5DSvDL9Y40KdOtXKdK6PEsykkgIakGMAZRH3U 68x8LquFfeajJkHWexhEgP8luMb7eIOggmHy3HvXBpsMutoI/Ii9AMMYCKCbceUr0Vp2 AlAqP2BdT+CJ3hwfKnVq1Higo8DcVdDciNr9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=cU5oMzy9G3hXfPf3fxcysldl39mPJlSJEPn+/YqMNchvGXpaQE2o0Xg8Upd7wXX9Tp B5ChMHRaXdTHTxe+m7Mi2bm41WaRMplbnt1kqQ7smA1UdTSRTPvtDNNKdS1QYDH08ns0 XJiIAg9SuXhoouma32EWK5O6SlqGpn6SwMOYk= Received: by 10.141.175.5 with SMTP id c5mr6598985rvp.80.1213888229272; Thu, 19 Jun 2008 08:10:29 -0700 (PDT) Received: by 10.141.211.15 with HTTP; Thu, 19 Jun 2008 08:10:29 -0700 (PDT) Message-ID: Date: Thu, 19 Jun 2008 23:10:29 +0800 From: "Junjie Peng" To: derby-dev@db.apache.org Subject: Re: [jira] Commented: (DERBY-3724) Converting big.sql to JUnit In-Reply-To: <1117045580.1213831665095.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4979_26601230.1213888229249" References: <218112514.1213724625262.JavaMail.jira@brutus> <1117045580.1213831665095.JavaMail.jira@brutus> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_4979_26601230.1213888229249 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Myrna: Thank you for the verbose instructions from you and Kathey! I accept your comments and will do the improvement. It seems most of my problem comes from not so good understanding of BaseJDBCTestCase, and I will reuse more reusable things. ---My IDE is Eclipse on Windows XP, I use subclipse to check and create the patch, the result starts with *"Index: D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java =================================================================== --- D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0) +++ D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0)"* I do know why it doesn't include a revision number. And "D:/myproject/java/eclipse/java" was deleted by hand. I have done another testing --- if I change a class file which has been submitted, the patch will include some Non-ASCII code. Maybe I should try SVN. ----Besides, I have another question: Where to put unit test codes for the unit test itself? When I do this converting, I have a trouble in doing unit testing for my new test case. So far, I just put the testing codes in the same class file, then delete all of them before submit. It is not so smart. How should we deal with this problem? Thank you! Regards Junjie 2008/6/19, Myrna van Lunteren (JIRA) : > > [ > https://issues.apache.org/jira/browse/DERBY-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606144#action_12606144] > > Myrna van Lunteren commented on DERBY-3724: > ------------------------------------------- > > Thanks for this great first effort! > > Kathey and I put our heads together and noticed the following: > > - what tool did you use to create the patch? Normally, patches are created > using svn diff from the top of the trunk. That way, the diff would have > something like: > ========================================================= > --- > java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision > 0) > +++ > java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision > 0) > > In your patch, we miss the revisions, and there's an extra level > ('derdy') - at Derby, we have to convention to not use @author tags. (ownership & > history is documented in JIRA and svn) > - BIG_TABLE_NAME should be static > - There should be no need for private Connection conn. The fixtures can > just call 'getConnection' (picking up from BaseJDBCTestCase) to connect to > the default db > - similarly, you don't need to use Statement stmt = > conn.createStatement(...), you can just use createStatement(int > resultSetType,int resultSetConcurrency) from BaseJDBCTestCase. > - it would be good to have a suite() method using defaultSuite. That way > the test would run automatically with both embedded and network > server/client, using cleanDatabaseSetup to remove all tables from the db > between fixtures. > - instead of validTabe() and validRows() it looks as if you should be able > to use one of the JDBC.assertFullResultSet() methods > - At the end of big.sql there are various tests commented out because at > one point it wasn't supported. Some of that functionality is (again?) > supported; you should be able to insert characters into tables with datatype > char, varchar, long varchar. (The max lengths are different per char - > should be in the manual). You should see if those test cases can be revived. > - the fixture 'testMixture' is based on a section that in big.sql has half > of it commented out, mentioning some problem with getting a > DRDAProtocolException. This section should make it into the test - if it > does still return a protocolException it can be commented out with reference > to a JIRA (I looked, but it doesn't appear one was logged, so that would > need to get done too, if reproducible). > - nit: we usually have the code inside a method indented 8 spaces. > > In general, there's a utility that we can use to convert .sql type tests to > junit type tests - org.apache.derbyTesting.functionTests.util.SQLToJUnit - > when you use it, a lot of the conversion should get done for you. > > > > Converting big.sql to JUnit > > ----------------------------- > > > > Key: DERBY-3724 > > URL: https://issues.apache.org/jira/browse/DERBY-3724 > > Project: Derby > > Issue Type: Task > > Components: Test > > Environment: windows XP Professional SP2, > > Reporter: Junjie Peng > > Assignee: Junjie Peng > > Fix For: 10.4.1.3 > > > > Attachments: patch.txt > > > > Original Estimate: 168h > > Remaining Estimate: 168h > > > > It is a task of "Converting old tests to JUnit ". It request > coverting "derdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/big.sql" > into a junit. Also, it is a task of 2008 GSoc. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > ------=_Part_4979_26601230.1213888229249 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Myrna:
    Thank you for the verbose instructions from you and Kathey! I accept your comments and will do the improvement. It seems most of my problem comes from not so good understanding of BaseJDBCTestCase, and I will reuse more reusable things.
    
 
   ---My IDE is Eclipse on Windows XP, I use subclipse to check and create the patch, the result starts with
 "Index: D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java
===================================================================
--- D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0)
+++ D:/myproject/java/eclipse/javaderdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java (revision 0)"
  I do know why it doesn't include a revision number. And "D:/myproject/java/eclipse/java" was deleted by hand. I have done another testing --- if I change a class file which has been submitted, the patch will include some Non-ASCII code. Maybe I should try SVN.
   ----Besides, I have another question:
        Where to put unit test codes for the unit test itself?  When I do this converting, I have a trouble in doing unit testing for my new test case. So far, I just put the testing codes in the same class file, then delete all of them before submit. It is not so smart. How should we deal with this problem?
     Thank you!
 
     Regards
     Junjie

 
2008/6/19, Myrna van Lunteren (JIRA) <jira@apache.org>:

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

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

Thanks for this great first effort!

Kathey and I put our heads together and noticed the following:

- what tool did you use to create the patch? Normally, patches are created using svn diff from the top of the trunk. That way, the diff would have something like:
=========================================================
--- java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java      (revision 0)
+++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/BigDataTest.java      (revision 0)

  In your patch, we miss the revisions, and there's an extra level ('derdy')
- at Derby, we have to convention to not use @author tags.      (ownership & history is documented in JIRA and svn)
- BIG_TABLE_NAME should be static
- There should be no need for private Connection conn. The fixtures can just call 'getConnection' (picking up from BaseJDBCTestCase) to connect to the default db
- similarly, you don't need to use Statement stmt = conn.createStatement(...), you can just use createStatement(int resultSetType,int resultSetConcurrency) from BaseJDBCTestCase.
- it would be good to have a suite() method using defaultSuite. That way the test would run automatically with both embedded and network server/client, using cleanDatabaseSetup to remove all tables from the db between fixtures.
- instead of validTabe() and validRows() it looks as if you should be able to use one of the JDBC.assertFullResultSet() methods
- At the end of big.sql there are various tests commented out because at one point it wasn't supported. Some of that functionality is (again?) supported; you should be able to insert characters into tables with datatype char, varchar, long varchar. (The max lengths are different per char - should be in the manual). You should see if those test cases can be revived.
- the fixture 'testMixture' is based on a section that in big.sql has half of it commented out, mentioning some problem with getting a DRDAProtocolException. This section should make it into the test - if it does still return a protocolException it can be commented out with reference to a JIRA (I looked, but it doesn't appear one was logged, so that would need to get done too, if reproducible).
- nit: we usually have the code inside a method indented 8 spaces.

In general, there's a utility that we can use to convert .sql type tests to junit type tests - org.apache.derbyTesting.functionTests.util.SQLToJUnit - when you use it, a lot of the conversion should get done for you.


> Converting big.sql  to JUnit
> -----------------------------
>
>                 Key: DERBY-3724
>                 URL: https://issues.apache.org/jira/browse/DERBY-3724
>             Project: Derby
>          Issue Type: Task
>          Components: Test
>         Environment: windows XP Professional SP2,
>            Reporter: Junjie Peng
>            Assignee: Junjie Peng
>             Fix For: 10.4.1.3
>
>         Attachments: patch.txt
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> It is a task of "Converting old tests to JUnit ". It request coverting  "derdy/java/testing/org/apache/derbyTesting/functionTests/tests/lang/big.sql" into a junit. Also, it is a task of 2008 GSoc.

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


------=_Part_4979_26601230.1213888229249--