db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (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 Sat, 24 Mar 2007 21:36:32 GMT

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


Mime
View raw message