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
