3 ms·
It's interesting -- this is not what I generally end up using DI for. The point of DI, a lot of the time, is to put seams into the program where you can test un
by obstinate 10y ago
It's interesting -- this is not what I generally end up using DI for. The point of DI, a lot of the time, is to put seams into the program where you can test units of a limited size. If you don't have some way of injecting behavior, you end up having some serious trouble when you have a module that brings together the behavior of many sub-modules (how do you test it?). That's something these short code example style articles never seem to capture for me.
- DenisM 10y agoWhy not test the whole thing together? That's what it was meant to be - a whole.
- solipsism 10y agoPlease don't ever work for NASA!
- bbcbasic 10y ago1. Speed of automated tests. 2. Often it is good to test the semantics of a sub system are solid before integrating it so that edge cases are routed out and at the very least it's easy to find where a break occurred.
- marvin 10y ago3. You might have external dependencies that are difficult or impossible to duplicate in your testing environment. Yes, stuff like this exists -- e.g. a medium-size retail bank will have at least a dozen, typically multiple-dozens of external contractors, each with their own APIs and testing environments.
- DenisM 10y agoThis is the only answer that speaks to me. Although I would think most often you would have such dependencies be API calls over network. It would me more prudent in such case to create a mock server rather than use DI. But yeah, in general API from a third party might call for DI. Thanks.
- bbcbasic 10y ago> only answer that speaks to me 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?
- DenisM 10y agoIf it's just a parser you need to test, there is no need for DI - just give the parser some files to chew on, and test it directly. 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.
- nkohari 10y agoBest case, you should build both integration tests (the entire system tested together) and unit tests (tests for individual pieces of the system isolated from others). The two types of tests will reveal different flaws in your code. Also, since it's difficult to write unit tests for tightly-coupled code, having a battery of unit tests can also help guide you towards a better overall architecture. 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.
- Roboprog 10y agoRather 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.
- yawaramin 10y agoSee my Twitter discussion with the post author, it touches on this https://twitter.com/yawaramin/status/827963406988742656 https://twitter.com/yawaramin/status/827963406988742656