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