Boost Users :
From: Ed Johnson (ed_at_[hidden])
Date: 2006-05-02 22:04:10
Paul Giaccone wrote:
> Ryo IGARASHI wrote:
>> On 3/23/06, Leif Gruenwoldt <leifer_at_[hidden]> wrote:
>>> Is there a way to test the private functions of a class without moving
>>> them into public scope during test?
>>> What are some strategies for this?
>> Try following evil hack.
>> // someclass_test.hpp
>> #define private public
>> #define protected public
>> #include <someclass.hpp>
>> #undef protected
>> #undef private
> Evil, evil, evil!
> Slightly less so is what I have done in my code. Define a variable (say,
> TESTING) in the makefile or preprocessor definitions of your test
> program. In your class definitin, change "private:" to the following:
> #ifdef TESTING
> Of course, you leave TESTING undefined (or make sure it is undefined) in
> your non-test program.
> It's perhaps not nice to look at, but it's less nasty than the above
> hack, IMO.
I wanted to add to your post. I am trying to figure out a good
solution to Leif's problem for my own project. Your solution seemed
good, but I also want the ability to test just the public interface,
without simultaneous access to the private data. When I use the #ifdef
TESTING solution, my unit tests never test the classes as they will be
used by an end user because all class data is always public. This could
lead to a false sense of security from my unit tests.
So, here is my addition that I think is more comprehensive.
- Separate tests of protected and private members into their own suites.
- Surround these suites with:
BOOST_AUTO_TEST_SUITE( A_Private );
BOOST_AUTO_TEST_CASE( A_Test1_Private )
A *p = new A();
BOOST_CHECK( p->privateData == 42 );
BOOST_AUTO_TEST_CASE( A_Test2_Private )
A *p = new A();
BOOST_CHECK( p->privateFunction() == "foo" );
By switching the TEST_PRIVATE definition on or off, I can test either
the pure public interface, or the private members temporarily exposed to
I should probably also surround my public interface tests with:
So, that I never accidentally mix the two groups, which would lead to a
weakened set of tests on my public interface.
You could also extend this to Protected members as well.
#ifndef TEST_PRIVATE || TEST_PROTECTED
#endif //TEST_PRIVATE || TEST_PROTECTED
You may want to keep protected tests separate from private tests as
well. (and vice versa)
Any thoughts on this strategy?
One potential problem I see is that all private data in every class in
the testee app becomes public to each test at the same time. This
strategy doesn't let you access private data one class at a time in your
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net