From: ian-news@this.is.invalid   
      
   Balog Pal wrote:   
   > On 12/26/2012 2:36 PM, Ian Collins wrote:   
   >>>   
   >>> Excuse me, but why on earth would one want a *mocking framework*   
   >>> to create a function?  Instead of just writing it and move along   
   >>> with actual job aimed?  Maybe this thing "misses" that utility for   
   >>> its sitting on the trivial list?   
   >>   
   >> Mocking free functions in a generic way saves you from having to   
   >> write them.  I often use my mocking framework to test code that   
   >> calls system or other C libraries.  Being able to specify return   
   >> values or expected parameters values is more often than not all   
   >> that is required in a unit test.   
   >   
   > I guess that applies to a different context -- one where the   
   > framework actually uses magic rather than standing in the way.   
   > Still, I can't see the 'save' part.   
      
   Well the question above: "but why on earth would one want a *mocking   
   framework* to create a function?" was more generic.   
      
   > The code we talk about is:   
   >   
   > Logger * pLogger;   
   > Logger& GetLogger() { return pLogger;}   
      
   *pLogger I hope!   
      
   > That is it. All of it. And one extre assignment to pLogger per test   
   > case -- replacing the one extra param per invocation in the PFA   
   > alternative.   
   >   
   > bool TestWithPFA   
   > {   
   >     MyLoger l;   
   >     foo1(1,2,3, l);   
   >     foo2(2,3,4, l);   
   >     foo3(2,2,2, l);   
   > }   
   >   
   >   
   > bool TestWithSingleton   
   > {   
   >     MyLoger l; pLogger = &l;   
   >     foo1(1,2,3);   
   >     foo2(2,3,4);   
   >     foo3(2,2,2);   
   > }   
      
   In this simple case, that's all you need to do.  In my case, I would   
   write   
      
   void testWithSingleton   
   {   
       MyLogger l;   
       GetLogger::willReturn( &i );   
       foo1(1,2,3);   
   }   
      
   So there isn't much difference (except I don't have to write a   
   definition of GetLogger).  In this specific case, the framework   
   neither impedes or enhances writing tests.  Where it really saves time   
   is when you have multiple functions and functions with parameters and   
   you want to be bale to check the vales passed.   
      
   I guess the "save" comes from a consistent interface for all mocked   
   free functions.   
      
   > Unless certainly the test is not interested in the singleton   
   > object's state, then it is even simpler:   
   >   
   > NullLogger l;   
   > Logger& GetLogger() { return l;}   
   >   
   > and the cases skip the fist line.   
   >   
   > I repeat my original question: what the heck can possibly be that   
   > test-ruining boogie related to singleton usage?   
      
   I'd like to know the answer to that as well.   
      
   > While for this subthread: what value a framework adds to this, and   
   > why is it really needed?   
      
   See above.   
      
   --   
   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)