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