Re:From dependency injection to dependency rejection
by Roboprog on Sunday February 05, 2017 @01:25PM
(#13573667)
Rather than simply condemning you, since I have had similar thoughts, I think the answer is "it depends".
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.
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.