From: ian-news@this.is.invalid   
      
   tom fogal wrote:   
   > Hi all,   
   >   
   > I often hit a problem testing code and haven't seen a good solution   
   > for it.  The issue is that I typically want to test code which is not   
   > 'exposed' and I'm curious if anyone has a better solution than I do.   
      
   The best technique is to expose the functionality.   
      
   > Here's a very simplified example: a module 'A' exposes a function 'F'.   
   > Internally, 'F' calls a function 'internal', which I'd like to test.   
   > In code:   
   >   
   > A.cpp:   
   >     static void internal() { ... }   
   >     void F() { internal(); }   
   >   
   > (Of course, in reality this is not simple forwarding; 'F' uses   
   > 'internal' merely as a tool among a more complicated series of tasks.)   
   >   
   > I can (and of course should) test to make sure 'F' fulfills its   
   > contract, but in many cases 'F' is complex.  'internal' of course has   
   > a contract as well, and if its not fulfilling it, I don't want to   
   > bother debugging 'F' until I know that 'internal' works.   
   >   
   > The solution I currently use is to define another internal-only   
   > symbol, 'test', which uses standard  asserts to verify   
   > 'internal' works as I expect.  When debugging, I insert a call to   
   > 'test' as the first line of some entry point (e.g. 'F').  When things   
   > work, I remove the line and if0-out 'test'.  This is of course   
   > undesirable.   
      
   It is, any manual process that impedes testing is a good excuse not to   
   do it when under time constraints.   
      
   > Other ideas (and reasons I've shied away): make 'internal' publically   
   > visible (then it's part of my interface!); exposing my test function   
   > as 'test_A' to be called in my test framework (adds one   
   > extra+unnecessary symbol per object to my release executables; still   
   > poor visibility to test framework [many test_A tests invoked from   
   > single call]); include my test framework into A.cpp (must link in test   
   > framework to release binaries; always need test framework to build,   
   > even if not debugging).   
   >   
   > Has anyone solved this in a better way?  (Or can convince me that me   
   > that one of my 'other ideas' isn't so bad.)   
      
   Consider putting the work done by internal() in to a discrete class of   
   its own and test that.  The more complexity from F() you can extract   
   into testable components, the easier it is to test (and maintain) it.   
      
   See "Refactoring: Improving the Design of Existing Code" by Martin   
   Fowler for inspiration.   
      
   --   
   Ian Collins   
      
      
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)