Re: [Boost-users] Testing private methods in Boost

Subject: Re: [Boost-users] Testing private methods in Boost
From: Richard (legalize+jeeves_at_[hidden])
Date: 2010-06-10 12:40:24

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

boost-users_at_[hidden] spake the secret code
<20100608145455.1645315v636o5csv_at_[hidden]> thusly:

>Is their a good strategy for testing private methods in a class using  
>Boost?  I am looking for something that is non-intrusive to the  
>developed code, but I can't think of any good ways without modifying  
>the code under test.

Don't be afraid to move the hard-to-test stuff to a new class and
delegate to the new class from the old one.  That doesn't change the
visibility of the old class and the new class needn't be published in
any public API if you want to keep it hidden.  However, the new class
can have methods with any visibility you like.  Michael Feathers calls
this technique "Break Out Method Object" in his book "Working
Effectively with Legacy Code", which I review here:
<http://legalizeadulthood.wordpress.com/2007/04/11/working-effectively-with-legacy-code-by-michael-c-feathers/>

Generally the situation you describe comes up most often when you try
to retrofit tests onto existing "legacy code" (code without unit
tests).  I find that when I practice test-driven development, then
things just work out naturally.

My tutorial on using Boost.Test also gives you a way to practice
test-driven development with C++ and Boost.Test:
<http://legalizeadulthood.wordpress.com/2009/07/04/c-unit-tests-with-boost-test-part-1/>
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>