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 (970) 419-8343 x27 fax (970) 223-6797 - Douglas Hofstadter dgsteffen@numerica.us
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.