Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: domain of manjula.kutty@gmail.com
 designates 66.249.82.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=HIrlLE1GAPJZrJYa77cCwiPdUDXIKBz0eidWgZrsgYpa1mQa/Bss/l1z62CbL8IQQ7sraFVrASO33MRfUKkCWMc1GABUs8b+Nd2A02JjyTmEg5gKrnpP1KVc+6n9IVgzzJXg5ID3eFkuzKV3H36uNVRzloGm4xWrhcY94zrtEKU=
Message-ID: <45C28BF4.3060405@gmail.com>
Date: Thu, 01 Feb 2007 16:55:16 -0800
From: Manjula G Kutty <manjula.kutty@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Junit test question
References: <45C0FCEF.6080000@gmail.com> <45C1032A.1090207@apache.org>
In-Reply-To: <45C1032A.1090207@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel John Debrunner wrote:

> Manjula G Kutty wrote:
>
>> Hi,
>>
>> I'm very new to the junit testing. So I picked lang/currentof.java as 
>> my first test to convert to junit. I did it with the very little 
>> knowledge I have and also with the help of the Wiki.  I got the test 
>> running to some extend but then I get some errors on the testUpdate. 
>> The error says "Invalid cursor state" . I tried using printf to see 
>> how the control goes and I could see the number of rows expected and 
>> got are 0. So it should come out of the  verifycount method, but it 
>> is not. There may be 3 reasons for this. Either I didn't understand 
>> the test fully or did something wrong while converting or there may 
>> be bug . Can someone please review the attached code(I know it is not 
>> a very clean code) and let me know what went wrong??
>
>
> One of the possibly unexpected facts about Junit when coming from the 
> old derby test harness is understanding the setup and tearDown methods 
> of a test class.  A test class contains fixtures, methods that start 
> with 'test' which are individual test cases. The setup and tearDown in 
> a test class are run for *each* fixture, thus I think twice in this 
> class, once for testUpdate() and once for testDelete(). I think a 
> common mistake is to assume they are run once for all the fixtures. 
> Could that be the case here?
>
> Another issue is that the order of fixtures is not guaranteed when 
> adding a suite using MyTest.class. This is intentional since fixtures 
> should be standalone test cases, thus if your test depends on 
> testUpdate() running before testDelete() you may see intermittant 
> problems.
>
>> One more question where will  the test database gets created? Even 
>> the test fails will the teardown method deletes all tables? If so is 
>> there a mechanism to access the database or copy the database 
>> instance when the test went wrong?
>
>
> Nothing exists at the moment, apart from working in a debugger. Please 
> feel free to implement something.
>
> Dan.
>
>
Here is  some information I gathered during the process of this test 
conversion. Thought it will be useful to people like me who are new to 
the junit world. Please feel free to add more information and also 
correct if I went wrong in any place.

The Wiki pages available in the Apache Derby site is very useful to a 
get initial startup.

setup and teardown methods will run per fixture. not once for the whole 
test.
By default all tests should be able to run in embedded or N/W server 
mode, without much user intervention

Most of the lang tests needs to be run with only embedded to avoid the 
overhead of testduration. There is no point in running the same tests
against networkserver if the test is doing simple SQL query tests. But 
tests for hold cursors and updateableResultSets are good candidates for 
the both.

There are some more Assert methods in the java/testing/junit package 
which can be used for most of SQL tests, like for getting the numberof 
rows updated for a prepared statement execution
you can use assertUpdateCount(PreparedStatement, rows expected); If the 
number of rows returned are not equal to the rows expected, the test 
will fail.

You can get rid of most of the try catch block with the assert methods. 
I used try/catch methods only for negative tests, where I have to catch 
the SQL exception. which can also be eliminated using the 
assertStatementError() method
To catch the SQLException you can use assertSQLState() method

If you are using eclipse for the test development then click on the 
class name and you can see all the methods in the right most tab and if 
you sort them you can view all the assert methods together.
Also there is a very good java doc for the Assert class. you can find it 
at http://junit.sourceforge.net/javadoc/junit/framework/Assert.html

It will be nice if we can add a functionality to keep the database as it 
is if the one test fails.

----will add more later

Thanks,
Manjula.