[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code <87pqfhijjd.fsf@avasys.jp> thusly:

Chris Cleeland writes:

...

I'm using the boost unit test framework to implement unit tests for code. I'm wondering if there is a best-practice for doing white-box testing/internal state inspection of types under test. My hack right now is to strip out "protected" and "private" from the header, but I hold my nose as I do that.

I don't use private members in the header file and put a subclass in the test implementation that makes the parent class' protected API public. [...]

I do this with legacy code, i.e. code that wasn't designed with testing in mind. However, I find that I don't need to do this when I practice TDD because the classes were designed to be testable in the first place. -- "The Direct3D Graphics Pipeline" -- DirectX 9 version available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com

Thanks to all for the suggestions! You are correct that I'm testing "legacy" code, though in this particular case the legacy code is completely open for change. But, I need unit tests before I go mucking about so I know that I haven't made things any worse than they are. On Wed, Dec 21, 2011 at 7:04 PM, Ahmed Badran wrote:

That is what I've come to accept as probably the cleanest possible solution without hacking/redefining "private"/"protected" in production vs. test code (even though it's far from what I would call elegant). For a class I essentially create a friend in a completely different "test" namespace, the unit tests go in that namespace and are linked against the object files to test them and validate class internals/invariants. The shipping code (headers) always have the 'missing' friend declarations, but as I said it's a 1 line that I've gotten to accept as the least ugly solution until I come across something that's more elegant.

For some reason I'm having difficulties implementing this suggestion. The "legacy" code lives in a namespace, e.g., // ClassToBeTested.hh namespace mycompany { namespace internal { class ClassToBeTested { ... }; } // namespace internal } // namespace mycompany If I understand the suggestion, I think I want to put the testing in a different namespace, e.g., // test_ClassToBeTested.cxx namespace mycompany { namespace internal { namespace test { // here lies the boost unit test stuff that I create struct ClassToBeTested_suite_fixture { ... }; BOOST_FIXTURE_TEST_SUITE( ClassToBeTested_suite, ClassToBeTested_suite_fixture ) ... here lie unit tests... BOOST_AUTO_TEST_SUITE_END() } } } So, in the declaration for ClassToBeTested, I should have something like class ClassToBeTested { public: // public interface protected: // protected members/methods friend class mycompany::internal::test::ClassToBeTested_suite_fixture; }; When I compile, the compiler complains that it does not know about namespace 'test' ]$ clang++ namespace_test.cxx namespace_test.cxx:4:46: error: no member named 'test' in namespace 'mycompany::internal' friend class ::mycompany::internal::test::ClassToBeTested_suite_fixture; ~~~~~~~~~~~~~~~~~~~~~~~^ namespace_test.cxx:6:8: error: expected external declaration } } } ^ 2 errors generated. The only way I've found around this is to forward declare ClassToBeTested_suite_fixture in the ClassToBeTested header, e.g., // ClassToBeTested.hh namespace mycompany { namespace internal { namespace test { class ClassToBeTested_suite_fixture; } class ClassToBeTested { ... }; } // namespace internal } // namespace mycompany Is this the technique that you use? I wonder, because it's more than one lane and still intrusive, and I'm wondering if I'm missing something. -- Chris Cleeland

On Thu, Dec 22, 2011 at 1:15 PM, Ahmed Badran wrote:

In your header (the class to be tested, you need to forward declare the test namespace and the tester class, e.g.

// ClassToBeTested.h

// You may be able to generate the forward declaration using a script and put it in an include file that you // include here. namespace test {     class TesterOfClassToBeTested; }

namespace myOtherNamespace { // optional     class ClassToBeTested     {         friend class test::TesterOfClassToBeTested;   // here's the one line :)         public:         private:     }; }

I had done that. But I think I've figured out my problem.

// TesterOfClassToBeTested.cpp

#include "ClassToBeTested.h"

#define foreach BOOST_FOREACH

using namespace std; using namespace boost; using namespace stage;

namespace test {     class TesterOfClassToBeTested     {         public:         TesterOfClassToBeTested()         {         }         void copy_constructor()         {             ClassToBeTested loc2;             ClassToBeTested loc(loc2);             BOOST_REQUIRE(loc.locIdStruct == loc2.locIdStruct);         }         ~TesterOfClassToBeTested()         {         }         private:     }; }

BOOST_AUTO_TEST_SUITE(TesterOfClassToBeTested)

struct fixture {     test::TesterOfClassToBeTested t; };

BOOST_FIXTURE_TEST_CASE(copy_constructor, fixture) {     t.copy_constructor(); }

BOOST_AUTO_TEST_SUITE_END()

What you've got above is a different usage of Boost::Unit than what I have. In my code, I have something like struct ClassToBeTested_suite_fixture { ... }; BOOST_FIXTURE_TEST_SUITE( ClassToBeTested_suite, ClassToBeTested_suite_fixture ) BOOST_AUTO_TEST_CASE( case1 ) { // code to do testing } BOOST_AUTO_TEST_CASE( case2 ) { // code to test a different case } BOOST_AUTO_TEST_SUITE_END() I designated friendship to ClassToBeTested_suite_fixture, but was trying to access the private data members in 'case1', 'case2', etc. That doesn't work because even though the cases inherit from the fixture, friendship does not get inherited. Indeed, when I went back to the header for ClassToBeTested and added a friend designation for ClassToBeTested::case1, it compiled just fine. I am a n00b to boost's unit test framework. I stumbled upon some examples that used the construct that I have been using, and they've worked just fine up until this case. Now that I have a need, I will have to learn just a little more. "Extreme Learning" :) Thanks for showing me a way that works for you. I'm certain it would have taken me a lot longer to figure that out to the point where I may have simply reverted to preprocessor tricks of "#define (protected|private) public" in the test case code. -- Chris Cleeland

on Thu Dec 22 2011, legalize+jeeves-AT-mail.xmission.com (Richard) wrote:

You may want to read through the 5-part tutorial I wrote on using Boost.Test:

http://legalizeadulthood.wordpress.com/2009/07/04/c-unit-tests-with-boost-te...

Gennadiy, if this tutorial is any good I suggest you link to it from the Boost.Test documentation. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code thusly:

on Thu Dec 22 2011, legalize+jeeves-AT-mail.xmission.com (Richard) wrote:

...

You may want to read through the 5-part tutorial I wrote on using Boost.Test:

http://legalizeadulthood.wordpress.com/2009/07/04/c-unit-tests-with-boost-te...

Gennadiy, if this tutorial is any good I suggest you link to it from the Boost.Test documentation.

When I published it, Gennadiy said he would link to it, but as near as I can tell, that never happened even though I wrote the tutorial 2+ years ago. -- "The Direct3D Graphics Pipeline" -- DirectX 9 version available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com

On Thu, Dec 22, 2011 at 3:05 PM, Mathias Gaunard wrote:

On 12/22/2011 12:25 AM, Chris Cleeland wrote:

...

I'm using the boost unit test framework to implement unit tests for code.  I'm wondering if there is a best-practice for doing white-box testing/internal state inspection of types under test.  My hack right now is to strip out "protected" and "private" from the header, but I hold my nose as I do that.

Thoughts/suggestions?

There are tricks to access private/protected members of a class without being a friend or anything like that.

http://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.ht...

Maybe that would be useful to you (haven't found a use for that yet)

That's a nifty, though convoluted, trick! So far nothing I've tried has been as straightforward as #define private public I do like the idea proposed in one of the comments on that blog where somebody suggested having a public_cast<> operator to cast away protections. -- Chris Cleeland

On Thu, Dec 22, 2011 at 5:28 PM, Richard wrote:

[Please do not mail me a copy of your followup]

boost-users@lists.boost.org spake the secret code thusly:

...

So far nothing I've tried has been as straightforward as #define private public

....which won't work on all compilers.

You are correct, but it works on the limited set of compilers targeted by this project. I am fortunate that I do not need to do the general case. -- Chris Cleeland