db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2460) Create a framework for writing unit tests that will access a private fields of derby classes.
Date Mon, 26 Mar 2007 19:21:32 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484201
] 

Kristian Waagan commented on DERBY-2460:
----------------------------------------

djd> Even if you were the only interested party I would still recommend contributing them,
it's fine if only one person has that itch. Others can only start to have the itch if there
is something there, a community can never build around something that isn't there. 

That is true, and if the support/framework is around, I will contribute such tests when I
find it appropriate. I just wanted to point out why I personally, for selfish reasons, write
such tests.

djd> Hmmm, while sometimes tests can help folks figure out how to use something, ideally
the class itself should document how it is to be used. :-)

I wish that was always true ;) But I  have even caught myself writing classes that I did not
fully understand... Writing the unit test, and by that having to deal with the interface and
think about it, helps me write better code. This is most helpful when writing new classes.


Although I don't have that many free cycles now, I'll try to be helpful to get the framework
into place.
I see these steps as a starting point:
 a) Get an example test into place (as a proof of concept; placing it, compiling it, running
it)
    If anyone have a candidate for such a test, speak up :) Then we can work it out on the
list.
 b) Add a top-level suite.
 c) Add an ant target to build the tests.

No actions will be imposed on any contributer that don't care about this feature at the moment.
The steps above will allow people to write tests for package-private classes, compile them
and run them manually by invoking a JUnit test runner on the top-level suite with the classes-directory
in the classpath. One problem must be solved to get there: Should the test classes be added
to 'classes' or to a separate destination?
An example of the latter is the 'classes.storeless' directory. Although I don't like numerous
classes-directories to pop up in the root directory, it is certainly less intrusive than having
to start filtering classes for the buildsources target(s).

Feel free to comment, I don't know the build scripts nor ant well enough to be very helpful
on this issue.

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


Mime
View raw message