l-september.org> 73ec3a48   
   From: ian-news@this.is.invalid   
      
   Tobias Müller wrote:   
   >   
   > Öö Tiib  wrote:   
   >> It has been several times asked in this thread: Why it is difficult to   
   >> create fake Singleton::instance() that is instrumented to return an   
   >> mock object that you want? Usual answer has been repeated "clear and   
   >> obvious" fact that DI is somehow simpler. Ok, but why and how?   
   >   
   > Usually, you test the external interface of a class if it behaves the way   
   > it has to. The use of a singleton in the class is an implementation detail   
   > and may thus easily be forgotten to test.   
      
   How can you test the behaviour of a class without testing how it   
   interacts its environment?  You most certainly can't if you develop test   
   first.   
      
   > With DI, you the "singleton" is part of the public interface of the class   
   > and can be tested without making assumptions on the internals of the class.   
      
   The internals of which class?  If you are testing how the class under   
   test uses the singleton, the internals of the real singleton are   
   irrelevant.  Your task is to check whether (and how) the appropriate   
   member functions are called and the behaviour of your code to given   
   return values.  To do this, you either have to jump through hoops of   
   fire to instrument the real code, or use a mock.   
      
   > With DI you have to specify an interface for those "singletons" that may be   
   > injected, with a real singleton one is tempted to just create, use and   
   > modify it ad hoc. A well defined interface is always good for testing.   
      
   Eh?  A singleton is no different from any other class form a testing   
   perspective.   
      
   > Of course you can replace a singleton with a mock if you really want to.   
   > But you cannot just take you library and build a test application around   
   > it. You have to exclude the complete singleton implementation from the   
   > original code and replace it with a different one.   
      
   Isn't that what mocking is all about?  At least in my world everything   
   that isn't part of the unit under test is mocked.  That's why we have   
   mocking frameworks to do the donkey work for us.   
      
   > In practice that means you have to replace some source files with others   
   > just for testing. You cannot use the original binary to build your tests   
   > around it, but have to compile (at least link) everything again. Possibly   
   > even with different compiler settings.   
      
   The compiler settings are irrelevant.  For unit testing, you don't want   
   to bring in all the real dependencies of the code under test, you want   
   to be able to monitor and control the interfaces your unit is using.  TO   
   do that, you mock them.   
      
   > I don't say that it's impossiple to test with a singleton mock, but DI is   
   > just more convenient.   
      
   Those of us on the other side if the fence disagree.  In practical, real   
   world situation I have not found this to be the case.   
      
   --   
   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)