I do not use mock objects when building my application, and I do not see the sense in using mock objects when testing. If I am going to deliver a real

I do not use mock objects when building my application, and I do not see the sense in using mock objects when testing. If I am going to deliver a real object to my customer then I want to test that real object and not a reasonable facsimile This reveals a fundamental misunderstanding of the purpose of mocking. If I test object A (and mock B for this purpose), I'm testing A - not the mock. Another test verifies behavior of concrete object B (while mocking A). Mocks themselves are not what is being tested. Of course it is possible that both A and B behave correctly in isolation (measured against expectations defined by unit tests), but they don't integrate well. In other words, expectations, assumptions verified by both unit test suites do not cover everything that's actually required for the components to form a functional system - there is a "gap". This is however not a flaw of Dependency Injection, but a natural shortcoming of unit tests as such. Obviously they are not a replacement for integration tests - but that works both ways. Different beasts. The advantage that unit tests have over integration tests is that they make it much easier to pinpoint sources of failures.