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. > Best regards, > Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
