Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <454B60E5.7020000@apache.org>
Date: Fri, 03 Nov 2006 07:31:49 -0800
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Adding a new test
References: <4549F0CF.3050503@sun.com> <wjo8slh1hoju.fsf@sun.com>
 <454A0DF3.8020205@apache.org> <454B52B9.2090805@sun.com>
In-Reply-To: <454B52B9.2090805@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Julius Stroffek wrote:
> Hi All,
> 
> Daniel John Debrunner wrote:
>> Sounds good, though if you have time looking at converting the 
>> existing test to JUnit would be beneficial for the community. Then you 
>> would be coming up to speed on the standard way rather than the old 
>> testing mechanism.
> Yes, I may do some work on converting tests to junit (also for DRDA 
> protocol). However I'm new to derby testing and I am just exploring it. 
> I have several questions related to tests. Sorrry, If some of those are 
> stupid... ;-)
> 
> 1.) The best way to run testing is to simply execute only one ant target 
> like (or more target for each set of tests like regression tests, 
> performance tests, etc.)
>       > ant runtests
> 
> Are we going to reach this kind of test execution?

Ant targets for running the JUnit tests were just committed.
See http://issues.apache.org/jira/browse/DERBY-2006 and the comments in it.

> 2.) As I understand it correctly the old harness tests and new junit 
> tests are kept in same directories. It is a bit confusing to me, I think 
> that it might be for other people as well. I down know what is a part of 
> which testing framework, which files are obsoleted, etc. Yes, of course, 
> it is possible to find it in a code but it takes much more time.

Yes they are, initially the tests were in a separate package and then I 
guess the community decided to switch to the layout we have today.
This is also a temporary state, the faster we can do the conversion the 
faster this problem disappears. :-)

> 3.) How one can easily recognize that this and that test was already 
> converted to junit? If I see a file currentSchema.sql, how could I 
> recognize that it is used in junit or the old harness? Would it be 
> possible to take out new junit tests to another package - something like 
> "org.apache.derby.testing.junit" or similar? Does this make sense?

For a java test it is easy, if the class extends from BaseTestCase or 
TestCase then it is a Junit test.

For the sql tests it is harder, one has to look at the JUnit test that 
runs the scripts and see if it is listed there. The language tests use 
the LangScripts class to run the SQL files, it has a list of about 15 
tests that run as JUnit fixtures now.

> 4.) I have written a test described in previous email (in the same 
> thread) and I was trying to run it as part of 
> org.apache.derbyTesting.functionTests.suites.All suite with the default 
> TestConfiguration. The suite method of the DRDAProtocolTest class looks as
> 
>    public static Test suite() {
>        return TestConfiguration.defaultSuite(DRDAProtocolTest.class);
>    }
> 
> And during execution the following exception is thrown
> testMultipleConenctions(org.apache.derbyTesting.functionTests.tests.extra.DRDAProtocolTest)java.sql.SQLException: 
> Invalid transaction state.
>        at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) 
> 
>        ...
> testMultipleConenctions(org.apache.derbyTesting.functionTests.tests.extra.DRDAProtocolTest)java.sql.SQLException: 
> A lock could not be obtaine d within the time requested
>        at 
> org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46) 
> 
>        ...
> Caused by: org.apache.derby.client.am.SqlException: A lock could not be 
> obtained within the time requested
>        at 
> org.apache.derby.client.am.Statement.completeSqlca(Statement.java:1713)
>        ...
>        ... 37 more
> 
> It is because the location of the databases for both embedded and 
> derbynet test configurations are same.

Not sure why, it seems more like there is an issue with your test. It 
seems to be leaving transactions open once the fixtures have finished.


> I may use prefixes for tables and check 
> usingEbedded/usingDerbyNet/usingDerbyNetClient and for each one choose a 
> different prefix. Yes, this works but I don't like it.
> 
> If I will use (as I found in all other tests I went through)
> 
>    public static Test suite()
>    {
>        TestSuite suite = new TestSuite();
>        suite.addTestSuite(DRDAProtocolTest.class);
>        return suite;
>    }
> 
> The test is executed only in embedded test configuration.
> 
> How can I run a test easily in multiple test configurations?

As above using the defaultSuite() method.

I've also added some more information to the wiki on how to do various 
items, please look at these pages:

http://wiki.apache.org/db-derby/DerbyJUnitTesting
http://wiki.apache.org/db-derby/DerbyJunitTestConfiguration
http://wiki.apache.org/db-derby/KillDerbyTestHarness

Thanks for working on the tests.
Dan.