I may also be crossing a culture barrier here.
In the UK, in all the offices I've worked as a programmer we've only ever referred to "Unit testing" as the automated kind, for example, when talking about coding. Even in casual meet-ups where we're 3 pints down and don't work together so we can say whatever we want xD But it's still not just British culture, but British Office Programmer culture.
Manually testing with stubbed out parts would just be lumped as a generic "QA testing", or as "Manual Integration Testing". But the manual part is always explicit, instead of implicit, so it doesn't even occur to me to use it to refer to anything else without explicitly saying "manual". Likewise, terms like Mock and Stub and Fake are all used in their appropriate parts with the tools we use (.NET = Moq, Java = Mockito, etc.).
So it doesn't even occur to me for it to refer to anything but that.
In other countries the terms may well be used in 'casual' meaning more often, or the hobbyist community may just not have the language flowing around as much (and me being more a part of the professional community may just mean I haven't noticed that).
As an aside, I recommend heading to some local meet-ups even if you aren't a professional. Professional Programmers that go on their own time to them tend to love what they do, so they'd love to talk to you about it. Hence why I keep popping into this thread xD
As for the use of DI, it's a good way of removing the extra functionality of something from you mind entirely. And if you're doing test-first development (where you write a unit test first, then write the code to make it past) it's very useful for that because you don't need to care what the function does and setting that up, you just need to care about the inputs and the outputs.
As for the value of test-first development, it's a very useful design tool.
* It gives a nice feedback cycle that's satisfying since it gives you tangible progress for code that maybe isn't so visibly rewarding.
* It manages to force you to really think about what you're writing and why, very useful when you're doing it for 7.5 hours a day with only 1 hour break.
* It also acts as living documentation of what the code does, a useful tool for sharing understanding with the next guy to look at your code (or yourself after a few sleeps).
* Documentation that also is self-proving, so if it's wrong the build will fail. Documentation falling out of date is very easy when working 7.5 etc etc.
* It helps catch it when you accidentally break something's contract, also useful when 7.5 etc.
So for programming in a business setting I can't recommend it enough. It's great. Honestly the first point is the real reason people do it, all the others are just icing on the cake. Unfortunately it's harder selling it to managers on the basis of "the warm fuzzy feeling seeing a red test go green gives me".
For casual stuff, that varies from developer to developer. For games, I don't bother except for maybe adding tests for the physics code or some other stuff where my instinct tells me it'll help (unless I'm deliberately experimenting with test-firsting a game, mostly for kicks and giggles. Figuring out some different ways to do tests for graphical rendering stuff was interesting). But for personal API-style stuff, whilst I'm not as strict yeah I try and do it still. Also a useful practice, or try out a new tool before you introduce it to work.