Daniel John Debrunner wrote:
Kristian Waagan wrote:
Andreas Korneliussen wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kristian Waagan wrote:
<>
Hi,
I still have a question regarding the placement of JUnit tests. I have
brought this up before, but got very little response (I did get some,
see below).
Do we want to support [unit] testing of package private classes?
Maybe it is sufficient to support testing the public methods of public
classes ?
Hi Andreas,
In my opinion, it is not.
There are some quite complex classes which are not part of the public
API. Testing these indirectly through the public API is a lot of work,
and it might be hard to construct all variations/codepaths.
I think Andreas meant testing a class through its public methods and
interfaces, not Derby's public API. E.g. a module implementation can be
tested through its api from org.apache.derby.iapi. That should be pretty
direct testing that is able to cover all of the code in the module.
I recently experienced this problem. I "solved" it by writing my own
unit test and placing it in the appropriate package, which was not
contributed to the community. But maybe this is more of an exception
than the general case. The existing code base does not have this kind of
tests.
I must have missed this test being discussed on the list, can you
provide a link to the archives so I can see the kind of issues you were
hitting.
If the consensus is not to support unit tests of this kind, I will
either write indirect tests instead or test less of the code. My worry
is the latter approach...
One argument could be that if you can't test a code through its public
api then there is something wrong with the code, but maybe that's
optimistic. That's why I'd like to see the example you hit.
Sorry for this short answer Dan.
I hope to write a better one tomorrow. Just to show that what I propose
is not a new idea, I recommend people to read this entry in the JUnit FAQ:
http://junit.sourceforge.net/doc/faq/faq.htm#organize_1
I guess maybe I have formulated myself a little poorly.
Regards,
--
Kristian
Thanks,
Dan.
