[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