Re: [Boost-users] [test] testing protected/private methods out of test suits

Subject: Re: [Boost-users] [test] testing protected/private methods out of test suits
From: Daryle Walker (darylew_at_[hidden])
Date: 2008-10-27 15:03:02

[I'm just catching up on two months of unchecked e-mail.]

On Sep 18, 2008, at 3:26 AM, M. Siebeneicher wrote:

> I tried to test protected/private class methods by declaring the  
> test-case-class as a friend of the class-to-test. The test-case- 
> class is defined by the macro BOOST_FIXTURE_TEST_CASE(T, F).  That  
> works fine as long as I encapsulate the test-case with  
> BOOST_AUTO_TEST_SUITE(suite_name) and BOOST_AUTO_TEST_SUITE_END().
>
> I'm not able to define the correct friend declaration, cause the  
> compiler . Can someone give me hint, please?
>
> the code looks like this:
[TRUNCATE]

The previous responses took three approaches:

1. How to properly declare a friendly test apparatus.
2. How to (temporarily) mess with the definitions of "protected" and  
"private" to make them publicly accessible, with various compiler- 
dependent degrees of success.
3. Question on why you're doing this and come up with workarounds.

I'm going to go on track 3 myself.  Protected and private methods  
ultimately exist to support public ones.  Therefore NO code should  
exist in non-public methods that can't be activated through some  
combination of public method calls (including friends).  This  
statement should definitely be followed for testing private methods.   
Protected ones have a slight problem in that a derived class could  
potentially use said methods with arbitrary sets of parameters that  
none of the public methods can do (falling within pre-conditions, of  
course).  If your public methods cannot fully exercise some protected  
ones, then you need to create a custom derived class for testing.   
This is especially important if some private method code can only be  
accessed when a protected method is called with unusual parameters.

For any method, no matter the accessibility level, make sure to do  
additional testing with derived classes using overrides if a method  
either is virtual or could call (directly or indirectly) a virtual  
method.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com