-september.org> ddeaddf9   
   From: ian-news@this.is.invalid   
      
   Tobias Müller wrote:   
   > Ian Collins  wrote:   
   >> I don't like making extra work for myself.  Maybe this stems form most   
   >> of my work being one layer above the operating system APIs, so I end up   
   >> mocking (often an automated process) a significant number of system   
   >> libraries.   
   >>   
   >> 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.   
   >   
   > System calls are a good example. They are not really singletons, but the   
   > same problems apply.   
      
   Along with the same solutions!   
      
   > So consider a unit test with where malloc or new deliberately fails at some   
   > point.   
   > In the case of not using DI (read "Allocators") the unittest itself cannot   
   > dynamically allocate memory without failing or having side effects on the   
   > actual test.   
      
   That isn't really a good example.  I have a number tests that use a   
   custom allocator library (mainly for leak checking).  All I do is within   
   a test, tell it the next allocation should fail.  Admittedly these tests   
   are primarily for a C code base where DI isn't an option, but the   
   technique is still sound.   
      
   --   
   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)