Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <24168581.1174989033193.JavaMail.jira@brutus>
Date: Tue, 27 Mar 2007 02:50:33 -0700 (PDT)
From: "Julius Stroffek (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2460) Create a framework for writing unit
 tests that will access a private fields of derby classes.
In-Reply-To: <32715455.1174053069235.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.