Hi
2012/12/1 Gilles Sadowski <gil...@harfang.homelinux.org>
> 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).
>
I agree with you (mea culpa). If we ever need these auxiliary methods, we
can increase their scope without breaking compatibility.
> 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!
>
>
> Plus it was fun to use introspection (!). I learned something!
> Best,
> Gilles
>
Thanks anyway for this interesting conversation. I think this is a nice
workaround, but sometimes the gap between "nice workaround" and "dirty
trick" is very narrow indeed. I just wanted to check with all of you guys
that I didn't go too far in the direction of the dirty tricks...
Best regards,
Sébastien
