Re: [Boost-users] [Unit-Test] How to test private functions

From: Paul Giaccone (paulg_at_[hidden])
Date: 2006-05-03 04:42:55

Ed Johnson wrote:

>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
>>public:
>>#else
>>private:
>>#endif
>>
>>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.
>>
>>Paul
>>    
>>
>
>Hi Paul,
>
>  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.
>  
>

I'm not sure why you say the class data is public. The #ifdef I was 
proposing is for member functions only, so the class data remains private.

That said, I've now moved to a less hacky approach, which is to define 
member functions used by the test programs only that call the private 
member functions. For example:

private:
    int foo(int a);

#ifdef TESTING
public:
    int foo_test(int a)
    {
       return foo(a);
    }
#endif

I'm not sure if this is a preferable alternative to your idea of 
separating members into their own test suites, but it certainly seems 
simpler.

Paul