db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-919) improve pattern for setting up junit tests
Date Wed, 15 Mar 2006 14:26:29 GMT
Kristian Waagan wrote:
> Answering these by mail, not Jira comment, as it is not the best way to 
> answer a lot of specific questions. Maybe I'll condense the discussion 
> and add a Jira comment later.
> Just to be clear, I do not primarily work on this issue. I just wanted 
> to bring out comments to get things started, and it does seem people 
> have some.
> 
> David Van Couvering (JIRA) wrote:
> 
>>     [ 
>> http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370400 
>> ]
>> David Van Couvering commented on DERBY-919:
>> -------------------------------------------
>>
>> I think it is great to have base unit test like this, although I agree 
>> with Andreas that this should be renamed.  This class is almost solely 
>> about obtaining connections using different frameworks, and is very 
>> JDBC-specific.  There are plenty of unit tests that have no need for 
>> this functionality.
>>   
> 
> 
> Yes, indeed. But then we are *almost* back to simply extending TestCase. 
> What tests not related to frameworks (and thus JDBC) need some kind of 
> common functionality? Including JDBC in the name seems like a solution. 
> Do we agree that non-JDBC tests should extend TestCase directly?
> 

I think it would be good to have a BaseTestCase which has access to the 
following:
* a TestConfiguration object
* and possibly some debug methods to log stack trace, print stuff.

BaseJDBCTestCase could extend this with some getConnection() methods.

>> I am not sure how this work integrates with/coincides with the work 
>> Andreas did to create a junit test type which allows you to run 'raw' 
>> JUnit tests under the harness.  Can you explain?
>>   
>
I think this work integrates well with the work to run tests a .junit.
You can confirm that by trying to run the sample testcase as .junit.

> 
> Andreas' work for running a "raw" JUnit test under the harness is not 
> affected. This is all about getting a connection and some other basic 
> functionality. It was written because the existing DerbyJUnitTest need 
> additional methods calls before getConnection() returns a valid 
> connection, and because TestUtil does not have a getConnection() (but 
> several other getConnection(arguments) methods). We have several choices:
> * Use TestUtil, maybe do some additional work on it.
> * Adapt/change DerbyJUnitTest (dependencies restrict what we can change 
> of existing API/behavior)
> * Write a new common class from scratch
>
> So far most of the comments I have received have been regarding 
> implementation, which was not my primary goal. Do we all agree what we 
> need, but we want to do it in different ways? Or are there still someone 
> out there that have more fundamental issues to comment on?
> 

I want:

BaseTestCase: a useful base TestCase which provides a TestConfiguration 
object, and some logging method
BaseJDBCTestCase: extends BaseTestCase, and additionally provides 
getConnection() methods.

How the getConnection() methods are implemented, is not the important 
issue to me. They may be implemented by calling TestUtil or implemented 
in the BaseJDBCTestCase itself. I do however think it is important to 
avoid forcing testcases to call methods to clean up potential 
side-effects from previous testcases.

Also, to run a TestCase as a test of type .junit, the testcase suite 
must be able to run stand-alone in a standard JUnit TestRunner .

<..>
>> - There are a lot of defaults being setup in a hardcoded fashion in 
>> resetState().  It would be better to have a section of static finals 
>> at the top with all the default values so that someone looking at this 
>> code can tell right away what they are.  Actually, looking at Andreas' 
>> TestConfiguration, that is a nice way of doing it . Having it as a 
>> separate class also seems to be useful and more coherent.
>>   
> 
> 
> One note here, is that it would not be possible to change the framework 
> with the current TestConfiguration. This would cause trouble for 
> exceptional cases (as the current JDBC4 testsuite) and if we want to run 
> useprocess=false and switch framework. Is this switching of framework 
> something we don't need?
> 
I do not see that we need switching framework in general. And .junit 
tests cannot be run with useprocess=false.

I think if you additionally supplied a getConnection(..) method which 
takes JDBCClient parameter, you could easily write special purpose 
testcases which do not use the default framework for getting the 
connectiom, if that is what you need.

> Also, it seems the harness uses all of "hostName", "derbyTesting.serverhost" and "derbyTesting.clienthost".
Can anyone shed some light on this?
I assume that derbyTesting.serverhost is the hostname for the derby 
server, derbyTesting.clienthost is the hostname for the client.


Andreas

Mime
View raw message