[
https://issues.apache.org/jira/browse/DERBY-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484386
]
Julius Stroffek commented on DERBY-2460:
----------------------------------------
Kristian, thank You for the writeup. I think You have written a lot of very
good stuff... ;-)
In general, <IMHO>, when we provide software and users start to use it in their
case
it will bring up some issues. These issues will get fixed after a while. If the
use case
chages (and/or users chage) new issues/bugs might be exposed. I think that
writing
more unit tests might also reduce the number of bugs exposed by a new use case.
Dan:
I think that the tests should try to use the class more in a way like it is used
by other code. Of course, the reason for extending the code with new
constructors,
methods, etc. might occur. For me, it seems to be acceptable to have those
methods
only for testing purposes when things are well explained in comments and
developers
would try to avoid this if possible.
Changing the visibility for class private members/methods to package private
only for tests is an issue. If the developer will try to implement something
in the package he may use other "test only used" package private members aswell.
It may lead to more interlacing code inside a package. I can not find
any other solution to this except well written comments.
---
I looked to derbynet/testProtocol.java test for investigation.
It invokes the test code written in org.apache.derby.impl.drda.TestProto
and TestProto is packaged to derbyTesting.jar. It seems that this
approach is already somehow implemented. My discoveries about how
thinks are currently done:
1.) The TestProto source is located in derby source tree and not testing source.
2.) All the classes are compiled to classes directory and the separate packaging
is based on
a) building derbynet.jar invokes org.apache.derbyBuild.classlister with
a list of classes which recursively prints out the classes on which
the specified list is dependent on.
b) building of derbytesting.jar is done by listing the files in the target
in the top level build.xml file
I understand why TestProto is not in a list produced by classlister
for derbynet.jar, but I do not understand how the classlister manages
to distinguish between derbynet.jar and derby.jar, etc. Are those jars
separated also by dependencies? How is the difference noticable
for classlister? I thought derbynet.jar classes use also classes from
derby.jar.
If we can manage the classlister to list also the derbyTesting classes
we can compile also these unit tests to the classes directory.
3.) When running the tests from jars, all the jar files are present on java
classpath.
The package in which TestProto is present is not sealed, even in insane
jars.
In general, most of the entries in jar files are not sealed.
Why only few entries in jar files are sealed? Is this a vulnerability?
Do we have a plan to seal more entries in the future?
Kristian, derbynet/testProtocol.java is a good candidate for the first test.
However,
I think that writing a dummy test instead with comments and explanations which
might
be used later as a template might be usefull.
> Create a framework for writing unit tests that will access a private fields
> of derby classes.
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-2460
> URL: https://issues.apache.org/jira/browse/DERBY-2460
> Project: Derby
> Issue Type: New Feature
> Affects Versions: 10.3.0.0
> Reporter: Julius Stroffek
> Priority: Minor
> Attachments: derby-2460-writeup-rev01.txt
>
>
> Create a testing framework for writing unit tests that will not test the
> functionality but some other properties of the code like DRDA protocol,
> conditions of B-trees, behavior of locking, etc. These tests may be written
> in a same way like the function tests are but they will not test the public
> API but some underlaying Derby functions. So, there is a need for the tests
> to access some package private properties/methods.
> The discussion about this issue took place on derby-dev couple of months ago.
> Please, see
> http://www.nabble.com/Testing-implementation-of-private-classes-tf2919330.html#a8158779
> for more information.
> Currently, there is an implementation of such a test in
> org.apache.derby.impl.drda.TestProto.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
