3 ms·
1. 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
by bbcbasic 10y ago
1. 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.