Hi,
2012/12/2 sebb <seb...@gmail.com>
> On 2 December 2012 09:58, Sébastien Brisard <sebastien.bris...@m4x.org>
> wrote:
> > 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...
>
> IMO test classes can use tricks that would not be suitable for the
> main code classes; reflection seems perfectly OK for test classes.
>
> However, of course tests may then break if private methods/fields etc
> are renamed, so it might be as well to add a comment to the code to
> say that the method is accessed from test code.
>
> That's an excellent suggestion. Will do that! Thanks a lot,
Sébastien
>
> > Best regards,
> > Sébastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
