Re: [Boost-users] Comments / Advice on using Boost Test Library

From: Matt Schuckmann (matt_at_[hidden])
Date: 2006-09-15 12:27:17

Dave Steffen wrote:
> Hi Folks,
> 
> We've been happy Boost Test Library customers for over a year now,
> slowly building up a set of unit tests for a large legacy code base.
> There's no question that it's Good Stuff.  Specifically, everything we
> do is some variation on a BOOST_AUTO_UNIT_TEST-y sort of thing; the
> extremely low amount of "typing overhead" is a big part of why so many
> people are writing unit tests (these unit tests are cheap, as unit
> tests should be).
> 
> What I'd like to ask the Boost community about is this: how to go
> about unit testing private class methods.
> 
> One answer is "don't; only unit test the public interface", which is
> fine as far as it goes.  However, most of our work is extremely
> mathematical, so it's not uncommon to see something like
> 
> class Base { ... public interface, etc ...};
> 
> class Derived : public Base
> {
> public:
> 
> 	... goodies in here ...
> 
> private:
> 
> 	double HelperFn1();
> 	bool   HelperFn2(int, double, KalmanFilter&);
> };
> 
> where HelperFn1 and HelperFn2 are extremely non-trivial mathematical
> operations.  Yes, exercising the public interface will signal mistakes
> in the helper functions, but can't do much to poke at them in depth,
> or help pinpoint exactly what chunk of math isn't right.  What we want
> is to be able to write unit tests that poke and prod such private
> member functions directly.
> 
> Another answer is "give your class a friend "tester" class, that uses
> its frienship to give the unit tests access to the class' guts".  We've
> been doing that for about a year now; not the most elegant, but an
> effective solution.  Unfortunately, it doesn't work for the thing I
> wrote this afternoon; I'll skip the details.
> 
> Another horrible, but effective, possibility is to 
> 
>     #define private public
>     #include "ClassToTest.h"
>     ...
> 
> (only in the unit test suites!) and muck about in the class's guts
> directly.  This is the only way I know of to get into the rather
> complicated template-class-heirarchy-interface-wrapper thing that I
> just built.
> 
> What kinds of techniques are you all using out there?
> 
> Thanks very much for any comments!
> 
> ----------------------------------------------------------------------
> Dave Steffen, Ph.D.      
> Software Engineer IV              Disobey this command!
> Numerica Corporation
> ph [phone] x27    
> fax [phone]                   - Douglas Hofstadter
> dgsteffen_at_[hidden]

I've always used the friend class approach. But like you I've found 
problems with it, specifically when I've implemented the pimple idiom.

I've never really found a good solution to this problem.
I suppose this doesn't really help but maybe it will spur some more 
discussion.

Matt S.