[
https://issues.apache.org/jira/browse/DERBY-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476236
]
Rick Hillegas commented on DERBY-2378:
--------------------------------------
This is an interesting topic which I would like to understand better. It seems
that there is a great deal of Derby's public API which is not visible in the
relatively small number of classes which we expose in the javadoc shipped with
our distributions. For instance, error messages and command line arguments are
part of Derby's public API which we document in our user guides but not in the
javadoc.
I think it is reasonable to test that Derby conforms to the behavior documented
in the user guides. Is the issue here the actual imports? Is there a best
practice for eliminating these imports but still verifying that the code agrees
with the user guides?
> SecureServerTest should not be using non-public apis
> -----------------------------------------------------
>
> Key: DERBY-2378
> URL: https://issues.apache.org/jira/browse/DERBY-2378
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.3.0.0
> Reporter: Daniel John Debrunner
>
> Functional tests should not be written against Derby's public api, not its
> internals.
> One reason is that it will make it harder to run the tests against different
> versions of Derby to test for regressions (e.g. run 10.3 tests against 10.4)
> The code imports these classes that are not part of the public api.
> import org.apache.derby.iapi.reference.Property;
> import org.apache.derby.iapi.tools.i18n.LocalizedResource;
> import org.apache.derby.impl.drda.NetworkServerControlImpl;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
