Re: [math] Using reflection to test private methods

[sebb <se...@gmail.com>]

On 30 November 2012 11:43, Luc Maisonobe <Lu...@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.brisard@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...

> Luc
>
>>
>> Thomas
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [math] Using reflection to test private methods

[Sébastien Brisard <se...@m4x.org>]

Hi,


2012/12/2 sebb <se...@gmail.com>

> On 2 December 2012 09:58, Sébastien Brisard <se...@m4x.org>
> wrote:
> > Hi
> >
> >
> > 2012/12/1 Gilles Sadowski <gi...@harfang.homelinux.org>
> >
> >> On Sat, Dec 01, 2012 at 09:39:04PM +0000, sebb wrote:
> >> > On 30 November 2012 11:43, Luc Maisonobe <Lu...@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.brisard@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [math] Using reflection to test private methods

[sebb <se...@gmail.com>]

On 2 December 2012 09:58, Sébastien Brisard <se...@m4x.org> wrote:
> Hi
>
>
> 2012/12/1 Gilles Sadowski <gi...@harfang.homelinux.org>
>
>> On Sat, Dec 01, 2012 at 09:39:04PM +0000, sebb wrote:
>> > On 30 November 2012 11:43, Luc Maisonobe <Lu...@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.brisard@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [math] Using reflection to test private methods

[Sébastien Brisard <se...@m4x.org>]

Hi


2012/12/1 Gilles Sadowski <gi...@harfang.homelinux.org>

> On Sat, Dec 01, 2012 at 09:39:04PM +0000, sebb wrote:
> > On 30 November 2012 11:43, Luc Maisonobe <Lu...@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.brisard@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

Re: [math] Using reflection to test private methods

[Sébastien Brisard <se...@m4x.org>]

Hi,


2012/12/2 Ted Dunning <te...@gmail.com>

> Google has a nice @ExposedForTesting annotation that they use for this.
>
> There are numerous instances in guava where otherwise private methods are
> exposed to the test suite for testing.  It makes a lot of sense, and there
> are no questions to anybody looking at the code about what is happening.
>  If you really want to do so, you can even implement a code walker that
> guarantees that all methods are annotated with the access level and level
> of stability.
>
> Franckly, I don't know where you guys find the time to study all these
libraries...
I'm amazed!

S

> On Sat, Dec 1, 2012 at 2:25 PM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
> > 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 doc
> >
>

Re: [math] Using reflection to test private methods

[Ted Dunning <te...@gmail.com>]

Google has a nice @ExposedForTesting annotation that they use for this.

There are numerous instances in guava where otherwise private methods are
exposed to the test suite for testing.  It makes a lot of sense, and there
are no questions to anybody looking at the code about what is happening.
 If you really want to do so, you can even implement a code walker that
guarantees that all methods are annotated with the access level and level
of stability.

On Sat, Dec 1, 2012 at 2:25 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:

> 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 doc
>

Re: [math] Using reflection to test private methods

[Gilles Sadowski <gi...@harfang.homelinux.org>]

On Sat, Dec 01, 2012 at 09:39:04PM +0000, sebb wrote:
> On 30 November 2012 11:43, Luc Maisonobe <Lu...@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.brisard@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org