db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Features of the JUnit test execution harness
Date Fri, 03 Feb 2006 17:59:45 GMT
Deepa Remesh wrote:
>>So I guess what you are saying is that if the test framework provides a
>>common mechanism to give a Connection to a derby database, it should go
>>through a DataSource, instead of using DriverManager ?
> I think we will need both mechanisms to get connection - using
> DataSource and DriverManager.
> J2ME/CDC/Foundation Profile is based on JSR169 for JDBC, which does
> not have java.sql.DriverManager class. So, here we need a mechanism to
> get a connection using javax.sql.DataSource.
> Using DataSource to get connection will not work in case of j9 vms
> (not foundation profile). In this case, database_enabler.jar is used
> for JDBC support and this does not have javax.sql.DataSource class.
> I'd appreciate if someone else familiar in this area can confirm this.
> Thanks,
> Deepa

I'm not familiar with this area, but wouldn't it in general be best to 
have a single method in the harness that returns a valid connection?
If the test is running in a J2ME/CDC/Foundation environment, it uses 
DataSource to get a connection, if it is in a j9 environment then it 
should use whatever is supported there. For most tests, how the 
connection is obtained is irrelevant, as long as it works!

I see that a few tests, for instance a test that is testing the 
different ways to get connections, would have the need to override such 
a standard method, but that's something that can be added when these 
tests are to be written in JUnit-style. However, depending on JVM and 
(un)available jars, some of the test cases in such a suite would have to 
be skipped anyway.

Instead of "learning" the harness how to get connections in X different 
ways, I would consider just extracting the required connection 
information (driver/framework prefix, database name, server, port etc) 
from the harness and then code how I get the connection in my test *if 
this is required*. The harness should only have to know about a minimal 
set of ways to get connections. With minimal set, I mean it has to know 
about one way to get a connection for all jvms/platforms (that we 
"support" or have the itch for). It does not need to know all the ways 
for all jvms/platforms.

 From the previous mails, the harness would have to know how to use 
DataSource and DriverManager. Are there jvms/platforms where neither of 
these will be able to produce a connection?


View raw message