[
https://issues.apache.org/jira/browse/DERBY-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484124
]
Kristian Waagan commented on DERBY-2460:
----------------------------------------
Hi Dan,
Your concerns are valid for this kind of tests. My primary goal with the
write-up was to try and document the issue to make it easier to understand.
I'll give you my view on your questions. I hope others will chime in as well.
Regarding the applicability of these kind of tests, I feel that they can be
very useful. One example is streaming-classes (Reader/Writer etc) where you
can have many boundary conditions. Writing the test also make you think more
about your code.
Also note that you in as good as all cases will be able to test the code
indirectly by manipulating state and feeding data through "public APIs". It's
just often a lot more tedious and harder to get as good coverage.
1) In these cases I think the coder can remove the test. The test exist because
the method/constructor is package-private. When this changes, the test should
go away. Depending on the itch of the coder, and the code change, there are
some alternatives: move the test to the "public domain" or rewrite the test. We
are using a version control system for our code, another coder can always bring
it back and adapt it later.
2) The test is meant as a tool for people that want to use it. I feel a lot
more confident that my code for a brand new class works when I have a unit test
for it in place. Whether I would write a unit test for a class or not, depends
a lot on what the class looks like. The problem you describe is the main factor
of my decision; how hard is it to create the required input for my class?
Although I basically agree with your reasoning on which tests are critical for
a project, I can't really see what's so different about running tests of
package-private classes. The main problem is of course that the interfaces are
not as stable as the public APIs. Because these tests are testing an isolated
area of the code (a single class), they should be very fast to run. I also
agree that we won't see that many tests for package-private classes, but why
should we miss out on the ones that are obvious candidates?
Would imposing this simple rule regarding package-private class tests be two
much? (assuming compiling them is enabled by default)
"If a package-private test does not compile after your changes, either delete
(parts of) it or fix it."
For the non-itching coders, this should equal a 'svn rm' and a one-line delete
from a suite class. For the itching coder, it would maybe require some thought
about why the test no longer compiles, if the change is safe and then some time
refreshing the test.
Personally I would also recommend running these tests by default, as they might
help you figure out why your functional tests suddenly started failing...
If I'm the only one feeling the need for writing package-private class tests, I
do not mind writing them and not contributing them :) I write them mostly for
my own sake anyway, but feel they can serve as documentation on how I intended
my class to be used.
For the information-hungry;
http://www-128.ibm.com/developerworks/library/j-test.html
> 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.
