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: [jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api
Date Wed, 28 Jun 2006 15:23:15 GMT
Bryan Pendleton wrote:
> Kristian Waagan (JIRA) wrote:
>  > I will add tests, but have to wait until the signatures have made it 
> into
>  > Mustang (I do have some tests already, but here I use the specific
>  > implementation classes, not the interfaces).
> 
> It seems to me that it's completely appropriate for tests to use
> specific implementation classes. Why is that a problem?

Hi Bryan,

You are correct that using specific implementation classes is completely 
appropriate in general. However, in this case, I would not be able to 
*easily* share the test code between the embedded and the client driver 
when running the JUnit test in our harness (I'm not very fond of the 
master based tests).

I could use reflection, add if's in a lot of places or duplicate large 
parts of the test code, but none of these seems like a good solution to 
me, considering the interfaces will most probably be updated with the 
new methods in about two weeks. The I can write the test code once and 
test all implementation classes with it.

Also, for the methods my patch added, there is not really that much to 
test - no functionality is added. I checked that the new methods did not 
break existing tests, and I also intend to add tests in a later patch.

For the remaining methods to be added under DERBY-1417, I thought I 
should create the patch and the test code and sit on it until Mustang 
has been updated with the signatures.
I submitted the first patch to make the next one smaller. It is a lot 
more important to review and test the latter one, since it will change 
code used for existing functionality.

> 
> Even if, in the longer run, we decide that the tests are more
> elegantly implemented using the official interfaces, not the
> underlying implementation classes, it seems to me it would be
> good to have the less-than-perfect tests now, and replace them
> later with superior tests, rather than having no tests at all.

I agree, but I decided to wait for the reasons mentioned above.

> 
> Furthermore, it seems like the advantage of at least some level
> of tests using the internal implementation classes, rather than the
> official JDK 1.6 interfaces, is that such tests could be runnable
> on JDK 1.4 and JDK 1.5 environments, meaning we'd have greater
> coverage of a larger amount of our code.

I see, but I fear that this will incur more work on the contributers 
writing tests. Maybe if we thought about it and came up with some 
guidelines for how to do this, it could work.

On the other hand, using the official interfaces is also important :)

> 
> Right now it scares me that there's this ever-increasing portion of
> the Derby implementation that's just a complete unknown to me, stuck
> as I am in my JDK 1.4/JDBC 3 world.

Do you think it's any better the other way around? ;)

Luckily, those who work on JDBC 4 features get to learn about the 
non-JDBC 4 parts of Derby as well!



Regards,
-- 
Kristian

> 
> thanks,
> 
> bryan
> 
> 
> 


Mime
View raw message