From: ian-news@this.is.invalid   
      
   Richard wrote:   
   > [Please do not mail me a copy of your followup]   
   >   
   > Ian Collins  spake the secret code   
   >  thusly:   
   >   
   >> Richard wrote:   
   >>> Ian Collins  spake the secret code   
   >>>  thusly:   
   >>>   
   >>>> Tobias Müller wrote:   
   >>>>> That's the point exactly. With DI you make clear which parts of   
   >>>>> the environment you are actually using.   
   >>>>   
   >>>> Maybe, but setting up a mock to enable a test should also make it   
   >>>> clear.   
   >>>   
   >>> It does.  The problem with link-time substitution is that I can't   
   >>> take one piece of code and make it use the link-time substitute and   
   >>> have another piece of code that uses the real thing and have them   
   >>> both live in the same executable.   
   >>   
   >> Which I'd consider to be positive.   
   >   
   > Fine.  We disagree.  I say it sucks, you say it's the greatest thing   
   > since sliced bread.   
      
   No, I just say it is a good idea.  On a project with thousands of tests,   
   having them in small independent chunks makes the TDD cycle a lot quicker.   
      
   >>> By using link-time substitution, I'm forced into having more test   
   >>> executables than I need.   
   >>   
   >> Use a test framework or IDE that works with multiple executable.   
   >   
   > Again, it sucks because it introduced unnecessary complexity into my   
   > build system, whereas if I just use an interface and DI for   
   > collaborators then all this stuff is under control of the test and I   
   > don't have to retrofit a whole bunch of changes to my build.   
      
   Build systems are automated, so the "complexity" is a one off that gets   
   introduced once and reused many times.   
      
   >>> If I use DI, then it's all under control fo the test and not the   
   >>> *linker*.   
   >>   
   >> But you have to create test versions of the collaborators, you can't   
   >> simply leave the job to the mocking framework.   
   >   
   > That doesn't follow, unless you equivocate "mocking framework" with   
   > "link time substitution".  Just exactly what "mocking framework" are   
   > you talking about?   
      
   It's one of my own design (in the spirit of Google mocks), augmented and   
   reused by many colleagues over the years.  It is designed to enable   
   CppUnit or Google test to be used with both C and C++ code.  A few years   
   ago a colleague added a python script that parses header files to   
   generate all of the mock stubs required to mock a C library.  When   
   mocking libraries, interposition is used.   
      
   >> I don't like making extra work for myself.   
   >   
   > ....unless it's in your build system?   
      
   Done once many years ago.   
      
   >> I'm still waiting (but not holding my breath) for a real world   
   >> example of why it's much easier to substitute the real code with the   
   >> mock when using DI.   
   >   
   > It's been my work experience at various employers since 2008.  That   
   > code is not open source for me to share and isn't available to me at   
   > this time.   
      
   A good smokescreen answer!   
      
   --   
   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)