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... > Luc > >> >> Thomas >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
