Re: [Boost-users] whitebox testing with boost unit test framework?

Subject: Re: [Boost-users] whitebox testing with boost unit test framework?
From: Richard (legalize+jeeves_at_[hidden])
Date: 2011-12-21 18:38:36

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

boost-users_at_[hidden] spake the secret code
<CALQcipZawapGNpqCswArgDdTqzMsB0cgnaU-J5D_6zoiiA7FDg_at_[hidden]> thusly:

>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?

Hard to suggest specific actions without seeing the particular code,
but my gut tells me that your class isn't designed for testability and
that's why you need to "stick your hands down its pants" in order to
sense what it's doing.

I've often "lifted" the visibility of something in a piece of legacy
code(*) in order to write a unit test for something I was changing.  I
might lift something from private to protected and then use a derived
class in my unit test to increase the visibility to public for the
purposes of the test.  Sometimes you can just derive your test fixture
from the system under test and that's good enough because in
Boost.Test, every test case derives from the test fixture, so it can
see protected items in the fixture or in the SUT.

(*) I use the term "legacy code" in the Michael Feathers "Working
Effectively with Legacy Code" sense: legacy code is any code that
isn't covered by unit tests.

Another technique I've used is to move the code to be tested to
another class with public members and have the original code delegate
to the new class to get things done.  This is a variant of the "Replace
Method with Method Object" refactoring, or sometimes it might be a
full blown "Extract Class".

Generally speaking, the smaller something is, the easier it is to
test.  While this may seem like a tautological statement, it's best
to keep this in mind when dealing with a large tangled legacy mess.
It's often easiest to backfill tests onto such code by extracting SUT
into something smaller that's easier to test.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 version available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>