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 13:21:32 GMT

    [ 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
> ---------------------------------------------------------------------------------------------
>                 Key: DERBY-2460
>                 URL: https://issues.apache.org/jira/browse/DERBY-2460
>             Project: Derby
>          Issue Type: New Feature
>    Affects Versions:
>            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.

View raw message