Isn't this just a more extreme version of extracting the private methods to another class where they would be public? - R -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Roman Neuhauser Sent: 16 September 2006 18:41 To: Dave Steffen Cc: boost-users@lists.boost.org Subject: Re: [Boost-users] Comments / Advice on using Boost Test Library # dgsteffen@numerica.us / 2006-09-15 10:49:46 -0600:
Sohail Somani writes:
From: boost-users-bounces@lists.boost.org
What I'd like to ask the Boost community about is this: how to go about unit testing private class methods.
#define private public #define protected public # include "MyClass.hpp" #undef private #undef protected
This is permissable in unit tests, I would think.
Yes, this is one of the alternate approaches I've been considering. We've got the "Bad" and the "Ugly". I'm still hoping the "Good" is out there somewhere... :-)
Extract bodies of those private methods to functors. Call those functors in/instead of your private methods, passing as arguments private data members that were accessed directly in the old methods. class somesuch { int x_, y_, z_; void doFoo() { x_ = y_ + z_; } } becomes struct Foo { int operator()(int x, int y) { return x + y; } } class somesuch { int x_, y_, z_; Foo foo; void doFoo() { x_ = foo(y_, z_); } } This doesn't solve the problem completely, but helps a lot and (AFAICT) always makes much sense from the design point of view, large private methods indicating that the class is mixing policy with mechanisms. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users