Testing every teeny tiny piece of a program is just stupid, and leads to more test code than product code, to no real benefit. (Java bean [blech!] getter/setter pairs, I'm looking at you!) ... Particularly very low level details that may end up being thrown out tomorrow morning after you rethink the problem.

OTOH, it's not a bad idea to make sure you test [most] every path, somehow.

At some point, though, sub-assemblies of larger apps are complicated enough to make testing them prudent. I'm not too proud to simply read an environment variable for things such as a server address/socket, though, rather than insisting on D/I. Other times, you gotta do what you gotta do, with complicated mocks and some kind of D/I.

Make sure requirements get tested, but not all [trivial] infrastructure really warrants the make-work.

So what if a dev home brews parser for instance, and you use that to read in files from a legacy system via ftp. You wouldn't test the parser code on its own? You test it all end to end?

If the "parser" has built-in logic to orchestrate remote file retrieval over FTP then DI is warranted, as per the other part of my previous answer.

If you're going to write just one kind of tests, you should write integration tests. But, if you have the time to write both, they will pay dividends.