From: Richard Howells (richard_at_[hidden])
Date: 2006-09-16 11:50:36
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_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Roman Neuhauser
Sent: 16 September 2006 18:41
To: Dave Steffen
Cc: boost-users_at_[hidden]
Subject: Re: [Boost-users] Comments / Advice on using Boost Test Library
# dgsteffen_at_[hidden] / 2006-09-15 10:49:46 -0600:
> Sohail Somani writes:
> > > From: boost-users-bounces_at_[hidden]
> >
> > > > 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_at_[hidden] http://listarchives.boost.org/mailman/listinfo.cgi/boost-users