On Sat, Dec 01, 2012 at 09:39:04PM +0000, sebb wrote:
> On 30 November 2012 11:43, Luc Maisonobe <luc.maison...@free.fr> wrote:
> > Le 30/11/2012 09:19, Thomas Neidhart a écrit :
> >> On Fri, Nov 30, 2012 at 8:06 AM, Sébastien Brisard <
> >> sebastien.bris...@m4x.org> wrote:
> >>
> >>> Hi,
> >>> I've already posted the same question in another thread [1], but I thought
> >>> having a dedicated thread would increase its visibility.
> >>>
> >>> Here is my problem. The new implementation of Beta.logBeta(double, double)
> >>> I'm currently working on relies on several private methods through a
> >>> rather
> >>> complex branching.
> >>> Due to this complicated branching, I find it much safer to have direct
> >>> tests for these private methods, instead of relying on the tests of
> >>> Beta.logBeta to validate these methods.
> >>> Therefore, in order to preserve encapsulation (these private methods
> >>> should
> >>> really remain private, and not package private, as I previously did [2]),
> >>> I
> >>> propose to use reflection in the unit tests to access these private
> >>> methods. I've tested this option locally, it seems to me that it is a
> >>> viable option.
> >>>
> >>> What do you think about this compromise?
> >>>
> >>
> >> imho, this is perfectly valid in such a specific case, and I had to do the
> >> same in other projects occasionally.
> >
> > +1, and I used the same trick already in some projects.
>
> +1 to using reflection in test cases if necessary.
> [I don't see why that even needs a vote!]
>
> However, I don't see what the issue is with package-private methods,
> so long as the reason for the removal of the private qualifier is
> documented.
>
> If 3rd party application code creates classes in o.a.c.m packages,
> then any problems that result are entirely up to them to resolve...
IMHO, that's really not the problem (i.e. I agree its theirs).
I just find it dirty from a desing point-of-view to have visibility scope
guided by how easy it would to test with Junit.
Scope in (useful) code should be guided by internal consistency (leaving any
testing consideration).
After some time, it becomes a soiurce or questioning ("Why is this code
package private?"). [And no, I don't think that it is enough reason to
state that reason (for "Junit" testing) is the documentation.]
Sébastien's case rarely occurs, and his workaround is fine. So is his
willingness to provide exhaustive coverage!
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
