[
https://issues.apache.org/jira/browse/DERBY-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483887
]
Daniel John Debrunner commented on DERBY-2460:
----------------------------------------------
Thanks for the clear write up on the issues, goals etc.
While it's not an itch of mine to write such tests, (I actually wonder how many
classes in Derby would fall into this testable category) I am wondering about
the impact of future development once a package-private test exists.
I can think of a couple of situations where an existing package-private test
could potentially hamper development:
1) Some coder notices that a method/constructor for a class is either only used
by the test or is not private only because of the test.
(assume this occured because of some change after the initial test). Can that
coder simply remove the method or make it private
even if it means removing some or all of the test?
2) A test is using some no-arg (or simple arg constructor) which a coder finds
only exists for the test, or needs to change to be more
complicated or needs to be made private/removed for security concerns. Such a
change makes the test useless since it can no
longer create the object to unit test, however in theory some
remaining/modified constructor can be used but it requires creating
other objects which may not be obvious how to create. Does the coder that is
making the class better have to spend time figuring
out how to keep the test running or can they just disable/remove the test?
For example a change from a no-arg constructor to one that requires a
SortController and to create a SortController requires a TransactionController,
thus moving away from being a unit test.
I can see that there is common ground that functional tests are critical for a
project, but beyond that, other types of tests
are just itches to scratched by those that want to. E.g. there's no expectation
that performance, stress or system tests
are run by every contributor to submit a patch, while there is an expectation
that some functional tests are run. I see these
package-private tests as falling into the category of those that want to do,
but it's not forced on others.
> 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.
